Internet Engineering Task Force (IETF)                    E. Juskevicius
Request for Comments: 6174                                     TrekAhead
Category: Informational                                       March 2011
ISSN: 2070-1721
        
Internet Engineering Task Force (IETF)                    E. Juskevicius
Request for Comments: 6174                                     TrekAhead
Category: Informational                                       March 2011
ISSN: 2070-1721
        

Definition of IETF Working Group Document States

IETF工作组文件状态的定义

Abstract

摘要

The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.

需要增强IETF数据跟踪器工具,使工作组(WG)主席能够向IETF参与者提供更多关于工作组文件状态和进展的信息,而不是当前可能的信息。

This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and their Delegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication.

本文档定义了需要添加到Datatracker的新状态和状态注释标记,以使工作组主席及其代表能够跟踪与其工作组相关联的互联网草稿(I-D)的状态。本文件还描述了IETF区域主管目前使用的所有先前实施的I-D状态和子状态注释标签的含义,以指示已发送至IESG进行评估和发布的I-D状态。

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/rfc6174.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc6174.

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许可证中所述的无担保。

Table of Contents

目录

   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................4
   3. I-D States Already Implemented by the Datatracker ...............5
      3.1. I-D Availability States ....................................5
           3.1.1. Expired .............................................6
           3.1.2. Active ..............................................6
           3.1.3. Replaces and Replaced By ............................6
      3.2. IESG Document States .......................................7
           3.2.1. Publication Requested ...............................7
           3.2.2. AD Evaluation .......................................8
           3.2.3. IESG Evaluation .....................................8
   4. New States and Status Annotation Tags for WG I-Ds ...............9
      4.1. Working Group I-D State Diagram ............................9
      4.2. Working Group I-D States ..................................11
           4.2.1. Call for Adoption by WG Issued .....................12
           4.2.2. Adopted by a WG ....................................12
           4.2.3. Adopted for WG Info Only ...........................13
           4.2.4. WG Document ........................................13
           4.2.5. Parked WG Document .................................13
           4.2.6. Dead WG Document ...................................14
           4.2.7. In WG Last Call ....................................14
           4.2.8. Waiting for WG Chair Go-Ahead ......................15
           4.2.9. WG Consensus: Waiting for Writeup ..................15
           4.2.10. Submitted to IESG for Publication .................15
      4.3. Working Group I-D Status Annotation Tags ..................16
           4.3.1. Awaiting Expert Review/Resolution of Issues Raised .16
           4.3.2. Awaiting External Review/Resolution of
                  Issues Raised ......................................16
           4.3.3. Awaiting Merge with Other Document .................16
           4.3.4. Author or Editor Needed ............................17
           4.3.5. Waiting for Referenced Document ....................17
        
   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................4
   3. I-D States Already Implemented by the Datatracker ...............5
      3.1. I-D Availability States ....................................5
           3.1.1. Expired .............................................6
           3.1.2. Active ..............................................6
           3.1.3. Replaces and Replaced By ............................6
      3.2. IESG Document States .......................................7
           3.2.1. Publication Requested ...............................7
           3.2.2. AD Evaluation .......................................8
           3.2.3. IESG Evaluation .....................................8
   4. New States and Status Annotation Tags for WG I-Ds ...............9
      4.1. Working Group I-D State Diagram ............................9
      4.2. Working Group I-D States ..................................11
           4.2.1. Call for Adoption by WG Issued .....................12
           4.2.2. Adopted by a WG ....................................12
           4.2.3. Adopted for WG Info Only ...........................13
           4.2.4. WG Document ........................................13
           4.2.5. Parked WG Document .................................13
           4.2.6. Dead WG Document ...................................14
           4.2.7. In WG Last Call ....................................14
           4.2.8. Waiting for WG Chair Go-Ahead ......................15
           4.2.9. WG Consensus: Waiting for Writeup ..................15
           4.2.10. Submitted to IESG for Publication .................15
      4.3. Working Group I-D Status Annotation Tags ..................16
           4.3.1. Awaiting Expert Review/Resolution of Issues Raised .16
           4.3.2. Awaiting External Review/Resolution of
                  Issues Raised ......................................16
           4.3.3. Awaiting Merge with Other Document .................16
           4.3.4. Author or Editor Needed ............................17
           4.3.5. Waiting for Referenced Document ....................17
        
           4.3.6. Waiting for Referencing Document ...................17
           4.3.7. Revised I-D Needed - Issue raised by WGLC ..........18
           4.3.8. Revised I-D Needed - Issue raised by AD ............18
           4.3.9. Revised I-D Needed - Issue raised by IESG ..........18
           4.3.10. Doc Shepherd Followup Underway ....................18
           4.3.11. Other - see Comment Log ...........................19
   5. Intended Maturity Level of WG Drafts ...........................19
   6. Security Considerations ........................................19
   7. References .....................................................19
      7.1. Normative References ......................................19
      7.2. Informative References ....................................20
   8. Acknowledgments ................................................20
   Appendix A: "IESG Document" States ................................21
      A.1. Definition of "IESG Document" States ......................21
         A.1.1. Publication Requested ................................21
         A.1.2. AD Evaluation ........................................21
         A.1.3. Expert Review ........................................21
         A.1.4. Last Call Requested ..................................22
         A.1.5. In Last Call .........................................22
         A.1.6. Waiting for Writeup ..................................22
         A.1.7. Waiting for AD Go-Ahead ..............................22
         A.1.8. IESG Evaluation ......................................22
         A.1.9. IESG Evaluation - Defer ..............................23
         A.1.10. Approved - Announcement to be sent ..................23
         A.1.11. Approved - Announcement sent ........................23
         A.1.12. RFC Ed Queue ........................................23
         A.1.13. RFC Published .......................................23
         A.1.14. DNP - Waiting for AD note ...........................23
         A.1.15. DNP - Announcement to be sent .......................23
         A.1.16. AD is Watching ......................................23
         A.1.17. Dead ................................................24
      A.2. IESG Document Substates ...................................24
         A.2.1. Point Raised - writeup needed ........................24
         A.2.2. AD Followup ..........................................24
         A.2.3. External Party .......................................25
         A.2.4. Revised ID Needed ....................................25
        
           4.3.6. Waiting for Referencing Document ...................17
           4.3.7. Revised I-D Needed - Issue raised by WGLC ..........18
           4.3.8. Revised I-D Needed - Issue raised by AD ............18
           4.3.9. Revised I-D Needed - Issue raised by IESG ..........18
           4.3.10. Doc Shepherd Followup Underway ....................18
           4.3.11. Other - see Comment Log ...........................19
   5. Intended Maturity Level of WG Drafts ...........................19
   6. Security Considerations ........................................19
   7. References .....................................................19
      7.1. Normative References ......................................19
      7.2. Informative References ....................................20
   8. Acknowledgments ................................................20
   Appendix A: "IESG Document" States ................................21
      A.1. Definition of "IESG Document" States ......................21
         A.1.1. Publication Requested ................................21
         A.1.2. AD Evaluation ........................................21
         A.1.3. Expert Review ........................................21
         A.1.4. Last Call Requested ..................................22
         A.1.5. In Last Call .........................................22
         A.1.6. Waiting for Writeup ..................................22
         A.1.7. Waiting for AD Go-Ahead ..............................22
         A.1.8. IESG Evaluation ......................................22
         A.1.9. IESG Evaluation - Defer ..............................23
         A.1.10. Approved - Announcement to be sent ..................23
         A.1.11. Approved - Announcement sent ........................23
         A.1.12. RFC Ed Queue ........................................23
         A.1.13. RFC Published .......................................23
         A.1.14. DNP - Waiting for AD note ...........................23
         A.1.15. DNP - Announcement to be sent .......................23
         A.1.16. AD is Watching ......................................23
         A.1.17. Dead ................................................24
      A.2. IESG Document Substates ...................................24
         A.2.1. Point Raised - writeup needed ........................24
         A.2.2. AD Followup ..........................................24
         A.2.3. External Party .......................................25
         A.2.4. Revised ID Needed ....................................25
        
1. Introduction
1. 介绍

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 IETF process [IDTRACKER].

IETF数据跟踪器是一个基于网络的系统,用于管理有关互联网草稿(I-D)和RFC、知识产权披露、联络声明以及IETF过程的其他几个重要方面的信息[IDTRACKER]。

The Datatracker is currently able to track and report on the status of I-Ds that have been submitted to the IESG for evaluation and publication. Appendix A of this document describes all of the document states and substate annotation tags used by IETF Area Directors (ADs) to indicate the status of I-Ds that have been sent to the IESG.

Datatracker目前能够跟踪并报告已提交给IESG进行评估和发布的I-D的状态。本文件附录A描述了IETF区域控制器(ADs)用于指示已发送至IESG的I-Ds状态的所有文件状态和子状态注释标签。

In contrast, the Datatracker has almost no ability to indicate the status and progression of I-Ds before they are sent to the IESG. The Datatracker can only track the availability status of I-Ds today (e.g., "Active", Expired", "Withdrawn", "Replaced by") and in some cases indicate which IETF Working Group (WG) an I-D is associated with (if any).

相比之下,数据跟踪器几乎没有能力在I-D发送到IESG之前指示其状态和进展。Datatracker只能跟踪当前I-D的可用性状态(例如,“活动”、“过期”、“撤销”、“替换”),在某些情况下,还可以指出I-D与哪个IETF工作组(WG)相关(如果有)。

Section 3 of this document contains a summary of the Datatracker's current ability to track and report on the status of I-Ds in the IETF document stream. The IETF document stream is defined in Section 5.1.1 of RFC 4844 [RFC4844].

本文件第3节概述了Datatracker当前跟踪和报告IETF文件流中I-D状态的能力。IETF文件流在RFC 4844[RFC4844]第5.1.1节中定义。

Section 4 of this document defines several new I-D states and I-D status annotation tags that need to be added to the Datatracker to enable status tracking and reporting for WG I-Ds.

本文档第4节定义了几个新的I-D状态和I-D状态注释标记,这些标记需要添加到Datatracker中,以支持WG I-Ds的状态跟踪和报告。

2. Conventions Used in This Document
2. 本文件中使用的公约

A "working group I-D" (WG I-D) is an Internet-Draft that has achieved consensus for adoption as a work item by a WG (compared to an individual submission I-D that has not, or has not yet, achieved consensus).

“工作组I-D”(工作组I-D)是一份已达成共识的互联网草案,供工作组作为工作项目通过(与尚未或尚未达成共识的个人提交I-D相比)。

The terms "WG I-D", "WG document", and "WG draft" are used synonymously throughout this document. The same is true for the plural case of each term.

术语“工作组I-D”、“工作组文件”和“工作组草案”在本文件中同义使用。每个术语的复数情况也是如此。

The terms "WG document" and "WG draft" are not intended to apply to any other document that may be reviewed, discussed, or produced by an IETF working group. Working group meeting materials such as Blue Sheets, agendas, jabber logs, scribe's notes, minutes, and presentation slides are not to be considered "WG documents" or "WG drafts" in the context of this document.

术语“工作组文件”和“工作组草案”不适用于IETF工作组可能审查、讨论或编制的任何其他文件。工作组会议材料,如蓝纸、议程、叽叽喳喳的日志、抄写员的笔记、会议记录和演示幻灯片,在本文件中不被视为“工作组文件”或“工作组草稿”。

The phrase "WG status of an I-D" is to be interpreted as referring to the state that an I-D is in, as defined in Section 4.2 of this document. This phrase does not refer to an I-D's availability status (e.g., "Expired", "Active", "Replaced by") as described in Section 3.1, or to any of the IESG states used by Area Directors to describe the status of I-Ds they may be evaluating.

短语“I-D的工作组状态”应解释为指I-D所在的状态,如本文件第4.2节所定义。该短语不指第3.1节所述的ID可用性状态(例如,“过期”、“活动”、“替换为”),也不指区域主管用于描述其可能正在评估的ID状态的任何IESG状态。

3. I-D States Already Implemented by the Datatracker
3. 数据跟踪器已实现的I-D状态

This section describes capabilities that are currently implemented in the Datatracker to track the status of I-Ds in the IETF document stream.

本节描述了Datatracker中当前实现的跟踪IETF文档流中I-D状态的功能。

The document availability states described in Section 3.1 are applicable to every I-D submitted to the IETF.

第3.1节中描述的文件可用性状态适用于提交给IETF的每个I-D。

The IESG document states and substate annotation tags described in Section 3.2 and Appendix A are only applicable to I-Ds that have been submitted to the IESG for evaluation and publication.

第3.2节和附录A中描述的IESG文件状态和子状态注释标签仅适用于已提交给IESG进行评估和发布的I-D。

The Datatracker currently has no I-D states or I-D status annotation tags to describe the WG status of any I-D.

Datatracker目前没有I-D状态或I-D状态注释标记来描述任何I-D的工作组状态。

3.1. I-D Availability States
3.1. I-D可用性状态

The Datatracker currently maintains availability status information for every I-D submitted to the IETF. The I-D availability states are as follows:

Datatracker当前维护提交给IETF的每个I-D的可用性状态信息。I-D可用状态如下所示:

- Expired - Active - Replaces - Replaced by - Withdrawn by Submitter - Withdrawn by IETF - RFC

- 过期-激活-替换-替换-由提交人撤销-由IETF撤销-RFC

The first four I-D availability states are explained in the following subsections. The other states are self-explanatory.

以下小节将解释前四种I-D可用性状态。其他国家是不言自明的。

Note that the Datatracker describes the status of some I-Ds with the phrase "I-D Exists". "I-D Exists" is the state that is manufactured by the Datatracker to describe I-Ds for which it has no other status information. For example, the tool currently uses "I-D Exists" to describe I-Ds that are not expired and that have not been sent to the IESG.

注意,Datatracker用短语“I-D存在”描述了一些I-D的状态。“I-D存在”是Datatracker制造的状态,用于描述没有其他状态信息的I-D。例如,该工具目前使用“I-D存在”来描述未过期且未发送至IESG的I-D。

3.1.1. Expired
3.1.1. 期满

An "Expired" I-D is a document that is more than six months old and that has not been updated or replaced by a newer I-D or an RFC.

“过期”身份证是指超过六个月的文件,并且没有更新或替换为新的身份证或RFC。

Every I-D has a normal lifespan of 185 days. An I-D will expire and be deleted from the I-D repository after six months unless it is updated or replaced by a newer version. One exception is that an I-D undergoing official evaluation by the IESG will not be expired before its status is resolved (e.g., the I-D is published as an RFC). IESG states that do not relate to a formal request to publish a document (e.g., "AD is Watching") do not prevent an I-D from expiring. [AUTHGUIDE]

每个I-D的正常寿命为185天。I-D将在六个月后过期并从I-D存储库中删除,除非更新或替换为新版本。一个例外是,正在接受IESG正式评估的I-D在其状态解决之前不会过期(例如,I-D作为RFC发布)。IESG声明,与发布文档的正式请求无关(例如,“AD正在监视”)不会阻止I-D过期。[授权指南]

3.1.2. Active
3.1.2. 忙碌的

An "Active" I-D is a document that is less than six months old and has not been updated or replaced by a newer I-D or an RFC.

“有效”I-D是指文件的有效期不到六个月,且未更新或替换为较新的I-D或RFC。

The "Active" availability state is applicable to individual I-Ds and WG I-Ds. The Datatracker may also use "Active" to describe the status of I-Ds under formal evaluation by the IESG and I-Ds in the RFC Editor Queue. As a result, the "Active" I-D availability state cannot be used to determine if an I-D is actively being developed by a WG. [WGDTSPEC]

“活动”可用性状态适用于单个I-D和WG I-D。Datatracker还可以使用“活动”来描述由IESG和RFC编辑器队列中的I-Ds进行正式评估的I-Ds的状态。因此,“活动”I-D可用性状态不能用于确定工作组是否正在积极开发I-D。[WGDTSPEC]

3.1.3. Replaces and Replaced By
3.1.3. 替换并替换为

The Datatracker uses "Replaces" and "Replaced by" to describe I-Ds that have been renamed and subsequently resubmitted to the I-D repository for some reason.

Datatracker使用“替换”和“替换为”来描述因某种原因已重命名并随后重新提交到I-D存储库的I-D。

Two common uses of "Replaced by" are as follows:

“替换为”的两种常见用法如下:

- The filename of an individual I-D that is being considered for adoption by a WG typically includes the name of its author (e.g., 'draft-author-wgname-topic-nn'). If the individual I-D is adopted by a WG it will be "Replaced by" a newer draft having a filename that includes the string 'ietf-' (e.g., 'draft-ietf-wgname-topic-00'); when the newer WG I-D is submitted to the I-D repository, it "Replaces" the older individual submission I-D.

- 工作组正在考虑采用的个人ID的文件名通常包括其作者的姓名(例如,“草稿作者wgname topic nn”)。如果工作组采用了单独的I-D,则该I-D将“替换为”文件名包含字符串“ietf-”(例如,“draft-ietf-wgname-topic-00”)的较新草案;当较新的工作组ID提交到I-D存储库时,它会“替换”较旧的个人提交I-D。

- The Datatracker also uses "Replaced by" to describe the final state of an I-D that has been published as an RFC; the I-D was "Replaced By" the RFC.

- Datatracker还使用“替换为”来描述已发布为RFC的I-D的最终状态;I-D被RFC“替换”。

Note that getting correct "Replaces" and "Replaced by" data into the Datatracker currently requires an explicit request by a WG Chair.

请注意,将正确的“替换”和“替换为”数据放入Datatracker当前需要工作组主席的明确请求。

Without such a request, an individual submission I-D will co-exist with the newer WG I-D that replaces it until the individual submission I-D eventually expires.

如果没有这样的请求,个人提交I-D将与更新的工作组I-D共存,直到个人提交I-D最终到期。

The Datatracker's ability to track "Replaces" and "Replaced by" information may need to be extended in the future to handle more complex cases such as the following:

未来可能需要扩展Datatracker跟踪“替换”和“替换为”信息的能力,以处理更复杂的情况,例如:

- Two or more I-Ds are merged into (i.e., "Replaced by") a single I-D; in such cases, the availability status of the (one) new I-D should indicate that the draft "Replaces" two or more older and previously separate I-Ds; and

- 两个或多个I-D合并为一个I-D(即,“替换为”);在这种情况下,(一)个新I-D的可用性状态应表明草稿“替换”了两个或两个以上以前单独的I-D;和

- One I-D is split or divided into two or more new I-Ds; in this case the availability status should indicate that one (older) I-D was "Replaced by" two or more newer I-Ds.

- 一个I-D被拆分或分成两个或多个新I-D;在这种情况下,可用性状态应表明一个(旧的)I-D被两个或更多新的I-D“替换”。

3.2. IESG Document States
3.2. IESG文件状态

In addition to tracking the availability status of every I-D, the Datatracker also maintains detailed information about the status and progression of I-Ds that have been sent to the IESG for evaluation and publication.

除了跟踪每个I-D的可用性状态外,Datatracker还维护已发送给IESG进行评估和发布的I-D状态和进展的详细信息。

All of the states used by Area Directors to indicate the status of I-Ds under evaluation by the IESG are defined in [IESGSTAT] and are reproduced for convenience in Appendix A.

[IESGSTAT]中定义了区域主管用于指示IESG评估的I-D状态的所有状态,并在附录A中复制以方便使用。

The following subsections describe some common interactions between three of the IESG I-D states and normal IETF WG processes. These interactions are relevant to several of the new WG I-D states defined in Section 4.

以下小节描述了三个IESG I-D状态与正常IETF工作组过程之间的一些常见交互。这些相互作用与第4节中定义的几个新的工作组I-D状态有关。

3.2.1. Publication Requested
3.2.1. 要求出版

When a WG has determined that at least rough consensus exists within the WG to advance an I-D, progressing the document is then the responsibility of the IESG (unless the IESG returns the I-D to the WG for further development). [RFC2418]

当工作组确定工作组内部至少存在推进I-D的大致共识时,IESG应负责推进该文件(除非IESG将I-D返回工作组进行进一步开发)。[RFC2418]

The "Publication Requested" state describes an I-D for which a formal request has been sent to the IESG to advance/publish the I-D as an RFC, following the procedures specified in Section 7.5 of RFC 2418 [RFC2418]. This state does not mean that an Area Director has reviewed the I-D or that any official action has been taken on the I-D other than to note that its publication has been requested.

“发布请求”状态描述了一个I-D,已向IESG发送正式请求,按照RFC 2418[RFC2418]第7.5节规定的程序,将I-D作为RFC进行提前/发布。该状态并不意味着区域主任已经审查了该I-D,或者已经对该I-D采取了任何官方行动,只是注意到已要求发布该I-D。

Many WG drafts enter the IESG state machine for the first time via the "Publication Requested" state. When an I-D advances through the IESG process, its IESG state will change to reflect its progress. This said, the WG status of the I-D should not change unless an AD or the IESG sends the I-D back to the WG for further development. The WG state of an I-D that is being progressed by the IESG is "Submitted to IESG for Publication", as defined in Section 4.2.10.

许多工作组草稿第一次通过“发布请求”状态进入IESG状态机。当I-D通过IESG过程时,其IESG状态将改变以反映其进度。这就是说,除非AD或IESG将I-D发送回工作组进行进一步开发,否则I-D的工作组状态不应改变。根据第4.2.10节的定义,IESG正在进行的I-D工作组状态“提交给IESG发布”。

3.2.2. AD Evaluation
3.2.2. 广告评价

The "AD Evaluation" state describes an I-D that the responsible Area Director has begun to review. The purpose of the AD's review is to verify that the I-D is ready for advancement before an IETF Last Call is started or before the document is progressed to the IESG as a whole.

“AD评估”状态描述了责任区域主管已开始审查的I-D。AD审查的目的是在IETF最后一次调用开始之前或在文件作为一个整体提交给IESG之前,验证I-D是否已准备好进行升级。

After evaluating an I-D, the responsible AD may decide that the document needs to be revised before it can be progressed further. The AD may send a working group I-D back to the WG that created it for revision.

在评估I-D后,负责的AD可能会决定需要对文件进行修订,然后才能进一步推进。广告可将工作组ID发送回创建工作组进行修订。

When an AD sends an I-D back to a WG for revision, the Datatracker will report the IESG state and substate status of the document as "AD Evaluation: Revised I-D Needed". If the required revisions are extensive, a WG Chair may decide to change the WG state of the I-D from "Submitted to IESG for Publication" to another WG state (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document") for as long as it takes the revised I-D to be developed. The IESG status of the I-D will continue to be "AD Evaluation: Revised I-D Needed" until the revised I-D becomes available.

当AD将I-D发送回工作组进行修订时,Datatracker会将文件的IESG状态和子状态报告为“AD评估:需要修订I-D”。如果所需修订内容广泛,工作组主席可决定将I-D的工作组状态从“提交给IESG发布”更改为另一个工作组状态(例如,“等待工作组主席批准”或“工作组文件”),只要需要修订I-D即可。I-D的IESG状态将继续为“AD评估:需要修订I-D”,直到修订I-D可用。

3.2.3. IESG Evaluation
3.2.3. IESG评估

The "IESG Evaluation" state describes an I-D that is being formally evaluated by the entire IESG. Every AD is able to raise any content or process issues he/she may have with the document. Issues that are blocking approval of the document are called "DISCUSS" comments. A "DISCUSS" with serious issues may cause a WG I-D to be returned to the WG for revision.

“IESG评估”状态描述了整个IESG正在正式评估的I-D。每个广告都能够提出他/她可能与文档有关的任何内容或流程问题。阻碍批准文件的问题称为“讨论”意见。与严重问题的“讨论”可能会导致工作组I-D返回工作组进行修订。

If the IESG sends an I-D back to a WG for more development, the Datatracker will report the IESG state and substate of the I-D as "IESG Evaluation: Revised I-D Needed" until a revised version of the I-D becomes available. During the time that the I-D is being revised, the WG Chair may decide to transition the I-D from the "Submitted to IESG for Publication" state into one of the earlier WG states (e.g., "Waiting for WG Chair Go-Ahead" or "WG Document").

如果IESG将I-D发送回工作组进行进一步开发,则Datatracker会将IESG状态和I-D的子状态报告为“IESG评估:需要修订I-D”,直到I-D的修订版本可用。在修改I-D期间,工作组主席可决定将I-D从“提交给IESG发布”状态转换为较早的工作组状态之一(例如,“等待工作组主席批准”或“工作组文件”)。

4. New States and Status Annotation Tags for WG I-Ds
4. WG I-Ds的新状态和状态注释标记

The status-tracking states described in Section 3 are currently implemented in the Datatracker; however, their scope is not broad enough to provide good visibility into the WG status of any I-D.

第3节中描述的状态跟踪状态目前在Datatracker中实现;然而,它们的范围不够广泛,无法很好地了解任何身份证的工作组状态。

This section describes new I-D states and I-D status annotation tags that need to be added to the Datatracker to make it possible for WG Chairs and/or their Delegates (e.g., WG Secretaries) to indicate the status and progression of the I-Ds associated with their WGs.

本节描述了需要添加到数据跟踪器中的新I-D状态和I-D状态注释标记,以使工作组主席和/或其代表(如工作组秘书)能够指示与其工作组相关的I-D状态和进展。

The WG I-D states defined in this section are a superset of the I-D states currently used across all IETF WGs. This is not to suggest or imply that all of the WG I-D states must be used by all WG Chairs to describe the status and progression of the I-Ds associated with their WGs. Chairs may use all or just some of the document states illustrated in Figure 1 to describe the WG status of their I-Ds as appropriate.

本节中定义的工作组I-D状态是当前在所有IETF工作组中使用的I-D状态的超集。这并不是建议或暗示所有工作组主席必须使用所有工作组I-D状态来描述与其工作组相关的I-D状态和进展。主席可酌情使用图1所示的全部或部分文件状态来描述其I-D的工作组状态。

4.1. Working Group I-D State Diagram
4.1. 工作组I-D状态图

Figure 1 is a state machine diagram that illustrates all of the WG I-D states defined in Section 4.2 of this document. The names of the WG I-D states are capitalized for clarity, and common state transitions are indicated via the solid, dashed, and dotted lines.

图1是一个状态机图,说明了本文件第4.2节中定义的所有工作组I-D状态。为清晰起见,WG I-D状态的名称大写,公共状态转换通过实线、虚线和虚线表示。

The WG I-D state machine illustrated in Figure 1 is intended to be a new front-end to the IESG I-D state machine [IESGIDSM] that is currently implemented in Datatracker.

图1所示的WG I-D状态机旨在成为当前在Datatracker中实现的IESG I-D状态机[IESGIDSM]的新前端。

Note that Figure 1 does not show every possible state transition. WG Chairs may move an I-D from any WG state to any other WG state as appropriate to describe the WG status of the document. The lack of an explicit path between two states does not mean that such a state transition is precluded.

注意,图1并没有显示所有可能的状态转换。工作组主席可酌情将身份证从任何工作组国家移至任何其他工作组国家,以描述文件的工作组状态。两个状态之间缺乏明确的路径并不意味着排除这种状态转换。

The first WG I-D state is "Call for Adoption by WG Issued" and its meaning and usage are defined in Section 4.2.1.

第一个工作组I-D状态为“发布的工作组采用要求”,其含义和用法见第4.2.1节。

One of several possible last states for a WG I-D is "Submitted to IESG for Publication". This state is defined in Section 4.2.10.

工作组ID的几个可能的最后状态之一是“提交给IESG出版”。该状态在第4.2.10节中定义。

         "I-D EXISTS": 'draft-author-wgname-topic-nn'  < - - .
                                     :                         .
 +---------------------------------------------------------------------+
 |  WG I-D State Machine             |                         .       |
 |                                   v                 (not adopted)   |
 |                                                            .        |
 |                   CALL FOR ADOPTION BY WG ISSUED  . . . . .         |
 |                     .             :                                 |
 |                    .              v                                 |
 |                   v                                                 |
 |             ADOPTED FOR     ADOPTED BY WG                           |
 |             WG INFO ONLY          .                                 |
 |                                   :                                 |
 |                                   :                                 |
 |    (individual I-D "Replaced by" 'draft-ietf-wgname-topic-00')      |
 |                                   :                                 |
 |                                   v                                 |
 |                                                                     |
 |       DEAD WG   <-------->   WG DOCUMENT  <-------->  PARKED WG     |
 |       DOCUMENT       ("Replaces" individual I-D)      DOCUMENT      |
 |                         .                                           |
 |                      .       ^          \                           |
 |                    .        /            \                          |
 |                   .        /              \                         |
 |                  .        v                \                        |
 |                 .                           \                       |
 |                .       IN WG    ---+         v                      |
 |                      LAST CALL     |                                |
 |               '          ^         +-->  WG CONSENSUS:              |
 |               ^          :                WAITING FOR               |
 |               '          v         +-->    WRITEUP                  |
 |               '                    |                                |
 |               ^      WAITING FOR   |          |                     |
 |               '       WG CHAIR  ---+          |                     |
 |                '      GO-AHEAD                v                     |
 |                 .                                                   |
 |                   .                    SUBMITTED TO IESG            |
 |          ("Revised ID Needed") - - < -  FOR PUBLICATION             |
 |                                                                     |
 |                                                                     |
 +---------------------------------------------------------------------+
                                    |
                                    v
                          IESG Document States
                            (see Appendix A)
        
         "I-D EXISTS": 'draft-author-wgname-topic-nn'  < - - .
                                     :                         .
 +---------------------------------------------------------------------+
 |  WG I-D State Machine             |                         .       |
 |                                   v                 (not adopted)   |
 |                                                            .        |
 |                   CALL FOR ADOPTION BY WG ISSUED  . . . . .         |
 |                     .             :                                 |
 |                    .              v                                 |
 |                   v                                                 |
 |             ADOPTED FOR     ADOPTED BY WG                           |
 |             WG INFO ONLY          .                                 |
 |                                   :                                 |
 |                                   :                                 |
 |    (individual I-D "Replaced by" 'draft-ietf-wgname-topic-00')      |
 |                                   :                                 |
 |                                   v                                 |
 |                                                                     |
 |       DEAD WG   <-------->   WG DOCUMENT  <-------->  PARKED WG     |
 |       DOCUMENT       ("Replaces" individual I-D)      DOCUMENT      |
 |                         .                                           |
 |                      .       ^          \                           |
 |                    .        /            \                          |
 |                   .        /              \                         |
 |                  .        v                \                        |
 |                 .                           \                       |
 |                .       IN WG    ---+         v                      |
 |                      LAST CALL     |                                |
 |               '          ^         +-->  WG CONSENSUS:              |
 |               ^          :                WAITING FOR               |
 |               '          v         +-->    WRITEUP                  |
 |               '                    |                                |
 |               ^      WAITING FOR   |          |                     |
 |               '       WG CHAIR  ---+          |                     |
 |                '      GO-AHEAD                v                     |
 |                 .                                                   |
 |                   .                    SUBMITTED TO IESG            |
 |          ("Revised ID Needed") - - < -  FOR PUBLICATION             |
 |                                                                     |
 |                                                                     |
 +---------------------------------------------------------------------+
                                    |
                                    v
                          IESG Document States
                            (see Appendix A)
        

Figure 1: WG I-D States and Common State Transitions

图1:WG I-D状态和公共状态转换

The Datatracker will be enhanced to automatically generate the following two state transitions for all WG drafts:

Datatracker将得到增强,以便为所有工作组草稿自动生成以下两种状态转换:

- A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00' file naming convention will be moved into the "WG Document" state automatically by the Datatracker when the WG Chair approves the posting of an I-D; and

- 符合“草案-ietf-wgname-topic-00”文件命名约定的版本-00 I-D将在工作组主席批准发布I-D时由数据跟踪器自动移至“工作组文件”状态;和

- A WG draft that is moved into the IESG state called "Publication Requested" will automatically be moved by the Datatracker into the WG state called "Submitted to IESG for Publication".

- 移到IESG状态(称为“已请求发布”)的工作组草稿将由Datatracker自动移到工作组状态(称为“提交给IESG进行发布”)。

All other WG I-D state transitions will require the WG Chairs or their Delegates to log in to the Datatracker to manually input the appropriate WG state to describe the WG status of an I-D.

所有其他工作组I-D状态转换将要求工作组主席或其代表登录到Datatracker,手动输入适当的工作组状态,以描述I-D的工作组状态。

Note that Figure 1 includes an arc from the "Submitted to IESG for Publication" state back to the "WG Document" state. This is one example of what may happen after an AD or the IESG as a whole sends an I-D back to a WG for revision. The WG chair may decide that the I-D needs further development and that it needs to return to the "WG Document" state for a while.

注意,图1包括从“提交给IESG以供发布”状态返回到“WG文档”状态的弧。这是广告或IESG作为一个整体将I-D发送回工作组进行修订后可能发生的情况的一个示例。工作组主席可决定I-D需要进一步发展,并需要在一段时间内回到“工作组文件”状态。

4.2. Working Group I-D States
4.2. I-D国家工作组

The WG I-D states defined in this section are a superset of the I-D states currently used across all IETF WGs.

本节中定义的工作组I-D状态是当前在所有IETF工作组中使用的I-D状态的超集。

All of the states described herein need to be added to the front-end of IESG state machine [IESGIDSM] that has already been implemented in the IETF Datatracker.

本文描述的所有状态都需要添加到IESG状态机[IESGISM]的前端,该状态机已经在IETF Datatracker中实现。

WG Chairs and their Delegates will be given the flexibility to use whichever of the WG I-D states they feel to be appropriate to describe the WG status of the I-Ds associated with their WG.

工作组主席及其代表将被赋予灵活性,可以使用他们认为合适的工作组I-D状态来描述与其工作组相关的I-D的工作组状态。

It is not suggested or implied that Chairs must use all of the I-D states defined herein to describe the status and progression of all I-Ds associated with their WGs; Chairs may use all of the WG I-D states, or just some of the states.

并非建议或暗示主席必须使用本文定义的所有I-D状态来描述与其工作组相关的所有I-D的状态和进展;主席可使用所有工作组I-D状态,或仅使用部分状态。

Note that an I-D that is not associated with a WG will be in a 'Null' state with respect to the WG state machine in Figure 1.

注意,对于图1中的WG状态机,与WG无关的I-D将处于“Null”状态。

4.2.1. Call for Adoption by WG Issued
4.2.1. 工作组发出通过呼吁

The "Call for Adoption by WG Issued" state should be used to indicate when an I-D is being considered for adoption by an IETF WG. An I-D that is in this state is actively being considered for adoption and has not yet achieved consensus, preference, or selection in the WG.

“工作组发布的采用要求”状态应用于指示IETF工作组何时考虑采用I-D。处于该状态的身份证明文件正在积极考虑采用,但尚未在工作组中达成共识、偏好或选择。

This state may be used to describe an I-D that someone has asked a WG to consider for adoption, if the WG Chair has agreed with the request. This state may also be used to identify an I-D that a WG Chair asked an author to write specifically for consideration as a candidate WG item [WGDTSPEC], and/or an I-D that is listed as a 'candidate draft' in the WG's charter.

如果WG主席同意该请求,该状态可用来描述某人要求WG考虑采用的I-D。该状态也可用于确定工作组主席要求作者专门编写的I-D作为工作组候选项目[WGDTSPEC]和/或工作组章程中列为“候选草案”的I-D。

Under normal conditions, it should not be possible for an I-D to be in the "Call for Adoption by WG Issued" state in more than one working group at the same time. This said, it is not uncommon for authors to "shop" their I-Ds to more than one WG at a time, with the hope of getting their documents adopted somewhere.

在正常情况下,一份身份证不可能同时在多个工作组中处于“工作组发出的通过呼吁”状态。这就是说,作者一次向多个工作组“购买”他们的ID,希望在某个地方采纳他们的文档,这种情况并不少见。

After this state is implemented in the Datatracker, an I-D that is in the "Call for Adoption by WG Issued" state will not be able to be "shopped" to any other WG without the consent of the WG Chairs and the responsible ADs impacted by the shopping.

在Datatracker中实现此状态后,未经工作组主席和受购物影响的负责广告的同意,处于“工作组发布的采纳呼吁”状态的I-D将无法“购买”给任何其他工作组。

Note that Figure 1 includes an arc leading from this state to outside of the WG state machine. This illustrates that some I-Ds that are considered do not get adopted as WG drafts. An I-D that is not adopted as a WG draft will transition out of the WG state machine and revert back to having no stream-specific state; however, the status change history log of the I-D will record that the I-D was previously in the "Call for Adoption by WG Issued" state.

请注意,图1包括从该状态到WG状态机外部的弧。这说明一些被认为是不被采纳为工作组草案的I-D。未被采纳为工作组草案的I-D将从工作组状态机转换出来,并恢复为没有特定于流的状态;但是,ID的状态更改历史日志将记录该ID以前处于“工作组发布的采用要求”状态。

4.2.2. Adopted by a WG
4.2.2. 工作组通过

The "Adopted by a WG" state describes an individual submission I-D that an IETF WG has agreed to adopt as one of its WG drafts.

“工作组采纳”状态描述了IETF工作组同意采纳为其工作组草案之一的个人提交I-D。

WG Chairs who use this state will be able to clearly indicate when their WGs adopt individual submission I-Ds. This will facilitate the Datatracker's ability to correctly capture "Replaces" information for WG drafts and correct "Replaced by" information for individual submission I-Ds that have been replaced by WG drafts.

使用此状态的工作组主席将能够清楚地表明其工作组何时采用个人提交I-D。这将有助于Datatracker正确捕获工作组草稿的“替换”信息,并纠正已被工作组草稿替换的个人提交I-D的“替换”信息。

This state is needed because the Datatracker uses the filename of an I-D as a key to search its database for status information about the I-D, and because the filename of a WG I-D is supposed to be different from the filename of an individual submission I-D.

之所以需要此状态,是因为Datatracker使用I-D的文件名作为键来搜索其数据库中有关I-D的状态信息,并且因为WG I-D的文件名应该不同于单个提交I-D的文件名。

The filename of an individual submission I-D will typically be formatted as 'draft-author-wgname-topic-nn'.

个人提交ID的文件名通常格式为“草稿作者wgname主题nn”。

The filename of a WG document is supposed to be formatted as 'draft-ietf-wgname-topic-nn'.

工作组文档的文件名应设置为“草案ietf wgname主题nn”。

An individual I-D that is adopted by a WG may take weeks or months to be resubmitted by the author as a new (version-00) WG draft. If the "Adopted by a WG" state is not used, the Datatracker has no way to determine that an I-D has been adopted until a new version of the I-D is submitted to the WG by the author and until the I-D is approved for posting by a WG Chair.

工作组采用的个人ID可能需要数周或数月的时间才能由作者重新提交为新的(00版)工作组草案。如果未使用“工作组采纳”状态,则在作者向工作组提交新版本的I-D以及工作组主席批准发布I-D之前,Datatracker无法确定I-D是否已被采纳。

4.2.3. Adopted for WG Info Only
4.2.3. 仅适用于工作组信息

The "Adopted for WG Info Only" state describes a document that contains useful information for the WG that adopted it, but the document is not intended to be published as an RFC. The WG will not actively develop the contents of the I-D or progress it for publication as an RFC. The only purpose of the I-D is to provide information for internal use by the WG.

“仅适用于工作组信息”状态描述了包含对采用该信息的工作组有用信息的文件,但该文件不打算作为RFC发布。工作组不会积极开发I-D的内容或将其作为RFC发布。I-D的唯一目的是提供信息供工作组内部使用。

4.2.4. WG Document
4.2.4. 工作组文件

The "WG Document" state describes an I-D that has been adopted by an IETF WG and is being actively developed.

“工作组文件”状态描述了IETF工作组已采用并正在积极开发的I-D。

A WG Chair may transition an I-D into the "WG Document" state at any time as long as the I-D is not being considered or developed in any other WG.

工作组主席可在任何时候将I-D转换为“工作组文件”状态,只要该I-D未在任何其他工作组中被考虑或开发。

Alternatively, WG Chairs may rely upon new functionality to be added to the Datatracker to automatically move version-00 drafts into the "WG Document" state as described in Section 4.1.

或者,工作组主席可以依赖添加到Datatracker的新功能,自动将版本00草案移动到“工作组文档”状态,如第4.1节所述。

Under normal conditions, it should not be possible for an I-D to be in the "WG Document" state in more than one WG at a time. This said, I-Ds may be transferred from one WG to another with the consent of the WG Chairs and the responsible ADs.

在正常情况下,I-D一次不可能在多个工作组中处于“工作组文档”状态。这就是说,在工作组主席和负责的广告部同意的情况下,I-D可以从一个工作组转移到另一个工作组。

4.2.5. Parked WG Document
4.2.5. 工作组文件

A "Parked WG Document" is an I-D that has lost its author or editor, is waiting for another document to be written or for a review to be completed, or cannot be progressed by the working group for some other reason.

“工作组文件”是指已失去作者或编辑、正在等待编写另一份文件或完成审查、或工作组因其他原因无法进行审查的ID。

Some of the annotation tags described in Section 4.3 may be used in conjunction with this state to indicate why an I-D has been parked, and/or what may need to happen for the I-D to be un-parked.

第4.3节中所述的一些注释标签可与该状态结合使用,以指示I-D停驻的原因,和/或I-D取消停驻可能需要发生的情况。

Parking a WG draft will not prevent it from expiring; however, this state can be used to indicate why the I-D has stopped progressing in the WG.

暂停工作组汇票不会阻止其到期;但是,此状态可用于指示工作组中的I-D停止进行的原因。

A "Parked WG Document" that is not expired may be transferred from one WG to another with the consent of the WG Chairs and the responsible ADs.

未过期的“工作组文件”可在工作组主席和负责广告的同意下从一个工作组转移到另一个工作组。

4.2.6. Dead WG Document
4.2.6. 死工作组文件

A "Dead WG Document" is an I-D that has been abandoned. Note that 'Dead' is not always a final state for a WG I-D. If consensus is subsequently achieved, a "Dead WG Document" may be resurrected. A "Dead WG Document" that is not resurrected will eventually expire.

“死工作组文件”是一个已被放弃的ID。请注意,“死亡”并不总是工作组ID的最终状态。如果随后达成共识,“死亡工作组文件”可能会复活。一个没有复活的“死工作组文档”最终将过期。

Note that an I-D that is declared to be "Dead" in one WG and that is not expired may be transferred to a non-dead state in another WG with the consent of the WG Chairs and the responsible ADs.

请注意,经工作组主席和负责的广告部同意,在一个工作组中被宣布为“死亡”且未过期的身份证可以转移到另一个工作组中的非死亡状态。

4.2.7. In WG Last Call
4.2.7. 在最后一次通话中

A document "In WG Last Call" is an I-D for which a WG Last Call (WGLC) has been issued and is in progress.

“工作组最后一次调用中”文件是一份已经发布并正在进行的工作组最后一次调用(WGLC)的ID。

Note that conducting a WGLC is an optional part of the IETF WG process, per Section 7.4 of RFC 2418 [RFC2418].

请注意,根据RFC 2418[RFC2418]第7.4节的规定,进行WGLC是IETF工作组流程的可选部分。

If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last Call" state can be used to track the progress of the WGLC. The Chair may configure the Datatracker to send a WGLC message to one or more mailing lists when the Chair moves the I-D into this state. The WG Chair may also be able to select a different set of mailing lists for a different document undergoing a WGLC; some documents may deserve coordination with other WGs.

如果工作组主席决定对ID进行工作组会议,“工作组最后一次会议”状态可用于跟踪工作组会议的进度。主席可配置Datatracker,以便在主席将I-D移动到该状态时向一个或多个邮件列表发送WGLC消息。工作组主席还可以为正在进行工作组讨论的不同文件选择一套不同的邮件列表;有些文件可能值得与其他工作组协调。

A WG I-D in this state should remain "In WG Last Call" until the WG Chair moves it to another state. The WG Chair may configure the Datatracker to send an e-mail after a specified period of time to remind or 'nudge' the Chair to conclude the WGLC and to determine the next state for the document.

在此状态下的工作组ID应保持“工作组最后一次呼叫”,直到工作组主席将其移至另一状态。工作组主席可将Datatracker配置为在指定时间段后发送电子邮件,以提醒或“推动”主席结束工作组LC并确定文件的下一个状态。

It is possible for one WGLC to lead into another WGLC for the same document. For example, an I-D that completed a WGLC as an "Informational" document may need another WGLC if a decision is taken to convert the I-D into a Standards Track document.

对于同一文件,一个WGLC有可能导致另一个WGLC。例如,如果决定将I-D转换为标准跟踪文档,则作为“信息”文档完成WGLC的I-D可能需要另一个WGLC。

4.2.8. Waiting for WG Chair Go-Ahead
4.2.8. 等待工作组主席继续

A WG Chair may wish to place an I-D that receives a lot of comments during a WGLC into the "Waiting for WG Chair Go-Ahead" state. This state describes an I-D that has undergone a WGLC; however, the Chair is not yet ready to call consensus on the document.

工作组主席可能希望将在工作组LC期间收到大量评论的ID置于“等待工作组主席继续”状态。该状态描述了经过WGLC的I-D;然而,主席尚未准备就该文件达成协商一致意见。

If comments from the WGLC need to be responded to, or a revision to the I-D is needed, the Chair may place an I-D into this state until all of the WGLC comments are adequately addressed and the (possibly revised) document is in the I-D repository.

如果需要回复工作组的意见,或需要对I-D进行修订,主席可将I-D置于这种状态,直到所有工作组意见得到充分处理,且(可能修订的)文件在I-D存储库中。

4.2.9. WG Consensus: Waiting for Writeup
4.2.9. 工作组共识:等待编写

A document in the "WG Consensus: Waiting for Writeup" state has essentially completed its development within the working group, and is nearly ready to be sent to the IESG for publication. The last thing to be done is the preparation of a protocol writeup by a Document Shepherd. The IESG requires that a document shepherd writeup be completed before publication of the I-D is requested. The IETF document shepherding process and the role of a WG Document Shepherd is described in RFC 4858 [RFC4858]

“工作组共识:等待编写”状态下的一份文件基本上已经完成了其在工作组内的开发,并几乎准备好发送给IESG出版。最后要做的事情是由文档管理员准备一个协议编写。IESG要求在要求发布身份证之前完成文件编写。RFC 4858[RFC4858]中描述了IETF文件管理过程和工作组文件管理者的角色

A WG Chair may call consensus on an I-D without a formal WGLC and transition an I-D that was in the "WG Document" state directly into this state.

工作组主席可在没有正式工作组LC的情况下就I-D达成共识,并将处于“工作组文件”状态的I-D直接转换为该状态。

The name of this state includes the words "Waiting for Writeup" because a good document shepherd writeup takes time to prepare.

此状态的名称中包含“等待编写”字样,因为编写好的文档需要时间。

4.2.10. Submitted to IESG for Publication
4.2.10. 提交给IESG出版

This state describes a WG document that has been submitted to the IESG for publication and that has not been sent back to the working group for revision.

本状态描述了一份工作组文件,该文件已提交给IESG出版,但尚未发送回工作组进行修订。

An I-D in this state may be under review by the IESG, it may have been approved and be in the RFC Editor's queue, or it may have been published as an RFC. Other possibilities exist too. The document may be "Dead" (in the IESG state machine) or in a "Do Not Publish" state.

处于这种状态的I-D可能正在接受IESG的审查,可能已经批准并在RFC编辑队列中,或者可能已经作为RFC发布。其他可能性也存在。文档可能处于“死”(在IESG状态机中)或“不发布”状态。

4.3. Working Group I-D Status Annotation Tags
4.3. 工作组I-D状态注释标签

In addition to indicating which state a working group draft is in, the Datatracker will allow several substate conditions to be identified and tracked. This section defines annotation tags that may be used to describe a condition that is affecting a WG I-D (e.g., why a document is in the state it is in) or to indicate an action needed to progress the document.

除了指示工作组草案所处的状态外,Datatracker还允许识别和跟踪几个子状态条件。本节定义了注释标签,这些标签可用于描述影响工作组I-D的条件(例如,文档为何处于其所处的状态)或指示文档进展所需的操作。

Annotation tags do not change the WG I-D state of WG drafts.

注释标记不会更改WG草稿的WG I-D状态。

Each of the annotation tags defined herein may be used to provide more information about the status of any WG draft in any state, if it makes sense to do so. Each annotation tag may be used by itself, or in combination with other tags.

本文定义的每个注释标记可用于提供关于任何状态下任何WG草案的状态的更多信息,如果这样做有意义的话。每个注释标记可以单独使用,也可以与其他标记组合使用。

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.

标记有此注释的工作组草稿应保留此标记,直到评审完成,并且可能直到评审中提出的任何问题得到解决。

4.3.2. Awaiting External Review/Resolution of Issues Raised
4.3.2. 等待外部审查/解决提出的问题

This tag means that someone (e.g., an author or editor of the WG draft, or a WG Chair) has initiated some other review of the document (e.g., sent it to another Standards Development Organization (SDO) for comments via a formal or informal liaison process), and the review has not yet been completed and/or the resolution of issues raised by the review has not yet been completed.

此标签表示有人(例如,工作组草案的作者或编辑,或工作组主席)已开始对文件进行其他审查(例如,通过正式或非正式联络流程将文件发送给另一个标准开发组织(SDO)征求意见),审查尚未完成和/或审查提出的问题的解决尚未完成。

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.

标记有此注释的工作组草稿应保留此标记,直到评审完成,并且可能直到评审中提出的任何问题得到解决。

4.3.3. Awaiting Merge with Other Document
4.3.3. 正在等待与其他文档合并

This tag means a decision has been made by someone (e.g., the document author, editor, or the WG Chair) to merge the I-D with one or more other I-Ds from the same (or another) working group.

此标签表示某人(如文档作者、编辑或工作组主席)已决定将ID与来自同一(或另一)工作组的一个或多个其他ID合并。

If the result of the merge is a new I-D having a different title, then the old I-D may be declared as being a "Dead WG Document". In such a case, the annotation tag should be changed from "Awaiting Merge with Other Document" to "Other - see Comment Log" and a description of the merge should be entered into the log for posterity.

如果合并的结果是一个新的ID具有不同的标题,那么旧的ID可能会被声明为“死的WG文档”。在这种情况下,注释标记应该从“等待与其他文档合并”更改为“其他-请参阅注释日志”,并且应该在日志中输入合并的描述,以供后代使用。

The Datatracker's regular 'Replaced by' information should also be set for the old I-Ds to make it easier to find the new merged document from the old documents.

还应为旧I-D设置Datatracker的常规“替换为”信息,以便于从旧文档中查找新的合并文档。

If the result of the merge operation is a revision to the old I-D, this annotation tag should be cleared when the revised (merged) I-D is submitted to the WG.

如果合并操作的结果是对旧I-D的修订,则在将修订(合并)的I-D提交给工作组时,应清除此注释标记。

4.3.4. Author or Editor Needed
4.3.4. 需要作者或编辑

This tag means an I-D has lost a primary author or editor, and that further work on the I-D cannot continue in an effective or efficient manner until a new author or editor is found.

此标记表示I-D失去了主要作者或编辑,并且在找到新作者或编辑之前,无法以有效或高效的方式继续对I-D进行进一步的工作。

This tag should be removed after a new primary author or editor is found.

找到新的主要作者或编辑器后,应删除此标记。

4.3.5. Waiting for Referenced Document
4.3.5. 正在等待引用的文档

This tag means that completion of the I-D is on-hold because the draft has a dependency on one or more other documents. A typical example is where an I-D depends on another IETF document that has not yet progressed to a point where it may be referenced; the dependency may be on one or more documents in other IETF Working Groups or on work in progress documents in other SDOs.

此标记表示I-D的完成被搁置,因为草稿依赖于一个或多个其他文档。一个典型的例子是,一个I-D依赖于另一个尚未发展到可以引用的IETF文件;依赖关系可能依赖于其他IETF工作组中的一个或多个文档,也可能依赖于其他SDO中的在制品文档。

This tag should be removed after the dependency is cleared.

清除依赖项后,应删除此标记。

4.3.6. Waiting for Referencing Document
4.3.6. 正在等待引用文档

This tag means that completion of the I-D is on-hold because one or more other documents are dependent on it, and the WG Chair wants to submit all of the documents to the IESG (for publication) simultaneously. This tag is the inverse of 4.3.5.

此标签表示I-D的完成被搁置,因为一个或多个其他文件依赖于此,工作组主席希望同时将所有文件提交给IESG(供发布)。该标签与4.3.5相反。

This tag should be removed after the dependency is cleared.

清除依赖项后,应删除此标记。

4.3.7. Revised I-D Needed - Issue raised by WGLC
4.3.7. 需要修订I-D-工作组提出的问题

This annotation may be used to flag an I-D that needs to be revised to address issues raised during a Working Group Last Call. This annotation may also be used to indicate when the I-D is in the process of being revised.

此注释可用于标记需要修改的I-D,以解决工作组上次通话期间提出的问题。该注释也可用于指示I-D何时处于修订过程中。

This tag should be removed after a revised version of the I-D is submitted to the WG.

在向工作组提交I-D修订版后,应移除该标签。

4.3.8. Revised I-D Needed - Issue raised by AD
4.3.8. 需要修改身份证-广告提出的问题

This annotation means the responsible AD raised one or more issues with the I-D during "AD Evaluation" and that the AD has sent the document back to the working group for revision. This annotation may also be used to indicate when the I-D is in the process of being revised.

此注释表示负责的AD在“AD评估”期间提出了一个或多个I-D问题,并且AD已将文件发送回工作组进行修订。该注释也可用于指示I-D何时处于修订过程中。

This tag should be removed after the revised version of the I-D is submitted to the WG.

该标签应在I-D修订版提交给工作组后移除。

4.3.9. Revised I-D Needed - Issue raised by IESG
4.3.9. 需要修订I-D-IESG提出的问题

This annotation means that one or more IESG members had issues with the I-D during "IESG Evaluation" and the document has been sent back to the working group for revision. This annotation may also be used to indicate that the revision to the I-D is in process.

此注释意味着一个或多个IESG成员在“IESG评估”期间对I-D存在问题,并且该文件已发送回工作组进行修订。该注释也可用于指示正在对I-D进行修订。

This tag should be removed after the revised version of the I-D is submitted to the WG.

该标签应在I-D修订版提交给工作组后移除。

4.3.10. Doc Shepherd Followup Underway
4.3.10. 谢泼德医生正在跟进

This annotation tag may be used to indicate that the Document Shepherd for the WG document has begun working on the writeup required to submit the document (to the IESG) for publication.

此注释标签可用于指示工作组文件的文件管理员已开始编写提交文件(至IESG)以供发布所需的文件。

It is possible that too many I-Ds may arrive in a shepherd's queue in too short a time, and the shepherd cannot create satisfactory writeups for all of the documents simultaneously.

可能有太多的I-D在太短的时间内到达shepherd’s队列,并且shepherd无法同时为所有文档创建令人满意的书写。

When this annotation tag is set, it means the Document Shepherd has started work on the writeup for the I-D. The absence or resetting of this annotation tag for an I-D in the "WG Consensus: Waiting for Writeup" state indicates the writeup has not yet been started, or has been put on-hold for some reason.

设置此注释标记时,表示文档管理员已开始I-D的writeup工作。在“WG Consensus:Waiting for writeup”状态下,缺少或重置I-D的此注释标记表示writeup尚未启动,或因某种原因被搁置。

4.3.11. Other - see Comment Log
4.3.11. 其他-请参阅评论日志

This annotation tag is a catch-all to indicate that someone (e.g., an author or editor of the document, the WG Chair, the Document Shepherd) has entered one or more comments about the current status of the I-D into the IETF Datatracker.

此注释标签是一个总括标签,用于指示某人(例如,文档的作者或编辑、工作组主席、文档管理员)已在IETF数据跟踪器中输入了一条或多条关于I-D当前状态的注释。

5. Intended Maturity Level of WG Drafts
5. 工作组草案的预期到期日水平

The IESG requires a WG I-D to have an "intended maturity level" associated with it (e.g., Informational, Proposed Standard, Experimental) before the I-D is submitted to the IESG for evaluation and publication. This information is also often requested by IETF participants.

IESG要求工作组I-D在提交给IESG进行评估和发布之前,具有与其相关的“预期成熟度水平”(例如,信息性、建议标准、实验性)。IETF参与者也经常要求提供这些信息。

I-D maturity levels were first defined in Sections 4 and 5 of RFC 2026 [RFC2026]. The names of the maturity levels in use today are:

首次在RFC 2026[RFC2026]第4节和第5节中定义了I-D成熟度水平。目前使用的成熟度级别名称如下:

* "Experimental" * "Informational" * "Best Current Practice" * "Proposed Standard" * "Draft Standard" * "Standard" * "Historic"

* “实验性”*“信息性”*“当前最佳实践”*“拟定标准”*“标准草案”*“标准”*“历史性”

The Datatracker may need to be enhanced to enable WG Chairs to input and/or change the intended maturity level of a WG draft before the I-D is sent to the IESG.

数据跟踪器可能需要增强,以使工作组主席能够在I-D发送给IESG之前输入和/或更改工作组草案的预期成熟度水平。

6. Security Considerations
6. 安全考虑

This document does not propose any new Internet mechanisms and has no security implications for the Internet.

本文件未提出任何新的互联网机制,对互联网没有任何安全影响。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[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月。

[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.

[RFC2418]Bradner,S.,“IETF工作组指南和程序”,BCP 25,RFC 2418,1998年9月。

[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月。

7.2. Informative References
7.2. 资料性引用

[AUTHGUIDE] Housley, R., Ed. (for the IESG), "Guidelines to Authors of Internet-Drafts", December 7, 2010, http://www.ietf.org/ietf/1id-guidelines.txt.

[作者指南]Housley,R.,Ed.(IESG),“互联网草稿作者指南”,2010年12月7日,http://www.ietf.org/ietf/1id-guidelines.txt.

[IDTRACKER] "The IETF Datatracker tool", Web Application: https://datatracker.ietf.org/, Version 3.12, February 2, 2011.

[IDTRACKER]“IETF数据跟踪器工具”,Web应用程序:https://datatracker.ietf.org/,版本3.12,2011年2月2日。

[IESGIDSM] "Diagram of Main I-D States", Web Application: https://datatracker.ietf.org/images/state_diagram.gif, October 21, 2002.

[IESGIDSM]“主要I-D状态图”,Web应用程序:https://datatracker.ietf.org/images/state_diagram.gif,2002年10月21日。

[IESGSTAT] "Main I-D States", Web Application: https://datatracker.ietf.org/idtracker/help/state/, Version 3.12, February 2, 2011.

[IESGSTAT]“主要I-D状态”,Web应用程序:https://datatracker.ietf.org/idtracker/help/state/,版本3.12,2011年2月2日。

[PROTO] Levkowetz, H. and Mankin, A., "Requirements on I-D Tracker Extensions for Working Group Chairs", Work in Progress, February 2007.

[PROTO]Levkowetz,H.和Mankin,A.,“工作组主席对I-D跟踪器扩展的要求”,正在进行的工作,2007年2月。

   [WGDTSPEC]  Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings
               of IETF 77, March 26, 2010,
               http://www.ietf.org/proceedings/10mar/minutes/wgdtspec
        
   [WGDTSPEC]  Juskevicius, E., "Minutes of wgdtspec BOF", Proceedings
               of IETF 77, March 26, 2010,
               http://www.ietf.org/proceedings/10mar/minutes/wgdtspec
        
8. Acknowledgments
8. 致谢

The author would like to thank Henrik Levkowetz and Allison Mankin for developing the original I-D [PROTO] that served as the starting point for this document, and Alfred Hoenes for his many comments and suggestions and for articulating the need for the "Adopted by a WG" state.

作者要感谢Henrik Levkowetz和Allison Mankin开发了作为本文件起点的原始I-D[PROTO],并感谢Alfred Hoenes的许多评论和建议,以及他阐明了“工作组采纳”状态的必要性。

The author would also like to thank Henrik Levkowetz, Russ Housley, Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis, and Joel Halpern for their comments and feedback along the way.

作者还想感谢Henrik Levkowetz、Russ Housley、Paul Hoffman、John Klensin、Pasi Eronen、Robert Sparks、Spencer Dawkins、Mary Barnes、Glenn Parsons、Marc Blanchet、Andy Malis和Joel Halpern在此过程中的评论和反馈。

Finally, the author also wishes to thank the IETF WG Chairs, ADs and other people who contributed their insights and suggestions in real-time during the wgdtspec BOF at IETF 77, and Lars Eggert, Tim Polk, Robert Sparks, Adrian Farrel and Alexey Melnikov for their comments, suggestions and DISCUSS points on the penultimate draft version of this document.

最后,作者还要感谢IETF工作组主席、ADs和其他在IETF 77的wgdtspec BOF期间实时提供见解和建议的人员,以及Lars Eggert、Tim Polk、Robert Sparks、Adrian Farrel和Alexey Melnikov的评论,关于本文件倒数第二稿的建议和讨论要点。

This document was initially prepared using 2-Word-v2.0.template.dot.

本文件最初使用2-Word-v2.0.template.dot编制。

Appendix A. "IESG Document" States

附录A“IESG文件”规定

This Appendix describes the status information currently stored in the IETF Datatracker tool for every I-D submitted to the IESG for publication. All of the terms and definitions in Sections A.1 and A.2 are copied from [IESGSTAT].

本附录描述了IETF Datatracker工具中当前存储的提交给IESG发布的每个I-D的状态信息。第A.1和A.2节中的所有术语和定义均从[IESGSTAT]复制。

It must be noted that I-Ds sent to the IESG for publication (termed "IESG Documents" in this Appendix) do not stay with the IESG until the day they are published as RFCs. After evaluation, the IESG may declare that some I-Ds deserve a "Do Not Publish" label. Other I-Ds may become "Dead". Some I-Ds may get sent back to their originators (WGs or otherwise), and the rest may go into the RFC Editor queue.

必须注意的是,发送给IESG发布的I-D(在本附录中称为“IESG文件”)在作为RFC发布之前不会留在IESG。评估后,IESG可能会宣布某些I-D应获得“请勿发布”标签。其他I-D可能会“死亡”。一些I-D可能会被发送回其发起人(WGs或其他),其余的可能会进入RFC编辑器队列。

Note that documents that are not tracked by the IESG (e.g., I-Ds for which no request has been made of the IESG) are in a null state with respect to the IESG state machine. The IESG state of an I-D that has no value assigned to the IESG state variable in the Datatracker's database is 'NULL'.

请注意,IESG未跟踪的文档(例如,未向IESG发出请求的I-D)相对于IESG状态机处于空状态。没有为Datatracker数据库中的IESG状态变量赋值的I-D的IESG状态为“NULL”。

A.1. Definition of "IESG Document" States
A.1. “IESG文件”的定义如下:
A.1.1. Publication Requested
A.1.1. 要求出版

A formal request has been made to advance/publish the document, following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the request could be from a WG Chair, or from an individual. Note: the Secretariat (iesg-secretary@ietf.org) is typically copied on these requests to ensure that the request makes it into the Datatracker. A document in this state has not (yet) been reviewed by an Area Director nor has any official action been taken yet, other than to note that its publication has been requested.

按照RFC 2418[RFC2418]第7.5节中的程序,已正式请求提前/发布文件;请求可以来自工作组主席,也可以来自个人。注:秘书处(iesg)-secretary@ietf.org)通常在这些请求上复制,以确保请求进入Datatracker。该州的文件尚未(尚未)由区域主任审查,也未采取任何正式行动,只是注意到其已被要求出版。

A.1.2. AD Evaluation
A.1.2. 广告评价

A specific AD (e.g., the "Area Advisor" for the WG) has begun their review of the document to verify that it is ready for advancement. The shepherding AD is responsible for doing any necessary review before starting an IETF Last Call or sending the document directly to the IESG as a whole.

一个特定的广告(例如,工作组的“区域顾问”)已开始审查该文件,以验证该文件是否已准备就绪。在开始IETF最后一次呼叫或将文件直接发送给IESG之前,牧羊广告负责进行任何必要的审查。

A.1.3. Expert Review
A.1.3. 专家审评

An AD sometimes asks for an external review by an outside party as part of evaluating whether a document is ready for advancement. MIBs, for example, are reviewed by "MIB doctors". Other types of reviews may also be requested (e.g., security, operations impacts,

广告有时要求外部人士进行外部审查,作为评估文件是否已准备就绪的一部分。例如,MIB由“MIB医生”审查。还可能要求进行其他类型的审查(例如,安全、运营影响、,

etc.) Documents stay in this state until the review is complete and possibly until the issues raised in the review are addressed.

等)文件保持这种状态,直到审查完成,可能直到审查中提出的问题得到解决。

Specific details on the nature of the review may be found in the "note" field associated with this state (i.e., within the Datatracker).

审查性质的具体细节可在与该状态相关的“备注”字段中找到(即,在Datatracker中)。

A.1.4. Last Call Requested
A.1.4. 请求的最后一个电话

The AD has requested that the Secretariat start an IETF Last Call, but the actual Last Call message has not been sent yet.

广告要求秘书处启动IETF最后一次呼叫,但实际的最后一次呼叫信息尚未发送。

A.1.5. In Last Call
A.1.5. 在最后一次通话中

The document is currently waiting for IETF Last Call to complete. Last Calls for WG documents typically last 2 weeks, and those for individual submissions last 4 weeks.

文档当前正在等待IETF最后一次调用完成。工作组文件的最后一次调用通常持续2周,个人提交的最后一次调用通常持续4周。

A.1.6. Waiting for Writeup
A.1.6. 等待写入

Before a standards-track or BCP document is formally considered by the entire IESG, the AD must write up a protocol action. The protocol action is included in the approval message that the Secretariat sends out when the document is approved for publication as an RFC.

在整个IESG正式考虑标准跟踪或BCP文件之前,AD必须编写一份协议行动。议定书行动包括在批准文件作为RFC出版时秘书处发出的批准信息中。

A.1.7. Waiting for AD Go-Ahead
A.1.7. 等待广告开始

As a result of the IETF Last Call, comments may need to be responded to and a revision of the I-D may be needed as well. The AD is responsible for verifying that all Last Call comments have been adequately addressed and that the (possibly revised) document is ready for consideration by the IESG as a whole.

作为IETF最后一次呼叫的结果,可能需要回复评论,并且可能还需要修改I-D。AD负责验证所有最后通话评论是否已得到充分处理,以及(可能修订的)文件是否已准备好供IESG作为一个整体进行审议。

A.1.8. IESG Evaluation
A.1.8. IESG评估

The document is now (finally!) being formally reviewed by the entire IESG. Documents are discussed in email or during a bi-weekly IESG telechat. In this phase, each AD reviews the document and airs any content or process issues they may have. Unresolvable issues are documented as "DISCUSS" comments that can be forwarded to the authors/WG. See the description of IESG substates in Section A.2 for additional details about the current state of the IESG discussion.

该文件现在(最终!)正由整个IESG进行正式审查。通过电子邮件或每两周一次的IESG telechat会议讨论文件。在这个阶段,每个广告都会审查文档并播放他们可能遇到的任何内容或流程问题。无法解决的问题记录为“讨论”意见,可转发给作者/工作组。有关IESG讨论当前状态的更多详细信息,请参见第A.2节中的IESG子状态说明。

A.1.9. IESG Evaluation - Defer
A.1.9. IESG评估-延迟

During a telechat, one or more ADs requested an additional two weeks to review the document. A defer is designed to be an exception mechanism, and can only be invoked once, the first time the document comes up for discussion during a telechat.

在telechat期间,一个或多个ADs要求额外两周时间审查该文档。延迟被设计为一种异常机制,并且只能在telechat期间文档第一次出现以供讨论时调用一次。

A.1.10. Approved - announcement to be sent
A.1.10. 已批准-待发送的公告

The IESG has approved the document for publication, but the Secretariat has not (yet) sent an official approval message.

IESG已经批准了该文件的发布,但秘书处尚未发出正式批准信息。

A.1.11. Approved - announcement sent
A.1.11. 已批准-已发送公告

The IESG has approved the document for publication, and the Secretariat has sent out the official approval message to the RFC editor.

IESG已批准发布该文件,秘书处已向RFC编辑发出正式批准信息。

A.1.12. RFC Ed Queue
A.1.12. 重复排队
   The document is in the RFC editor Queue (as confirmed by
   http://www.rfc-editor.org/queue2.html)
        
   The document is in the RFC editor Queue (as confirmed by
   http://www.rfc-editor.org/queue2.html)
        
A.1.13. RFC Published
A.1.13. RFC出版

The I-D has been published as an RFC.

I-D已作为RFC发布。

A.1.14. DNP - waiting for AD note
A.1.14. DNP-等待广告通知

Do Not Publish (DNP): The IESG recommends against publishing the document, but the writeup explaining its reasoning has not yet been produced. DNPs apply primarily to individual submissions received through the RFC Editor. See the "note" field for more details on who has the action item.

请勿发布(DNP):IESG建议不要发布该文件,但解释其理由的书面文件尚未产生。DNP主要适用于通过RFC编辑器收到的个人提交。有关谁拥有该操作项的更多详细信息,请参见“备注”字段。

A.1.15. DNP - announcement to be sent
A.1.15. DNP-待发送的公告

The IESG recommends against publishing the document. The writeup explaining the IESG's reasoning has been produced, but the Secretariat has not yet sent out the official "Do Not Publish" recommendation message.

IESG建议不要发布该文件。解释IESG理由的书面文件已经制作完成,但秘书处尚未发出正式的“请勿发布”建议信息。

A.1.16. AD is watching
A.1.16. 广告在看

An AD is aware of the document and has chosen to place the document in a separate state in order to monitor it (for whatever reason). Documents in this state are not actively tracked by the IESG in the sense that no formal request has been made to publish or advance the

广告知道该文档,并已选择将该文档置于单独的状态,以便对其进行监视(无论出于何种原因)。IESG没有积极跟踪该州的文件,因为没有正式请求发布或推进该州的文件

document. The AD has chosen to put the I-D into this state, to make it easier to keep track of (for his or her own reasons).

文件广告选择将身份证置于这种状态,以便于跟踪(出于他或她自己的原因)。

A.1.17. Dead
A.1.17. 死去的

The document is "Dead" and is no longer being tracked (e.g., it has been replaced by another document having a different name, it has been withdrawn, etc.)

该文档已“失效”,不再被跟踪(例如,它已被另一个具有不同名称的文档替换,它已被撤回,等等)

A.2. IESG Document Substates
A.2. IESG文件子状态

Note that the annotation tags described in this section were defined circa 2002. If these conditions were modelled today, they would most likely be modelled as annotation tags rather than as substates.

请注意,本节中描述的注释标记大约是在2002年定义的。如果今天对这些条件进行建模,它们很可能被建模为注释标记,而不是子状态。

A.2.1. Point Raised - writeup needed
A.2.1. 提出的问题-需要编写

IESG discussions on the document have raised some issues that need to be brought to the attention of the authors/WG, but those issues have not been written down yet. (It is common for discussions during a telechat to result in such situations. An AD may raise a possible issue during a telechat and only decide as a result of that discussion whether the issue is worth formally writing up and bringing to the attention of the authors/WG).

IESG对该文件的讨论提出了一些需要提请作者/工作组注意的问题,但这些问题尚未记录下来。(电视演讲期间的讨论通常会导致这种情况。广告可能会在电视演讲期间提出一个可能的问题,并且只会在讨论之后决定该问题是否值得正式撰写并提请作者/工作组注意)。

A document stays in the "Point Raised - writeup needed" substate until *ALL* IESG blocking comments that have been raised have been documented.

文档将保留在“提出的点-需要写入”子状态中,直到已提出的*所有*IESG阻止注释被记录。

A.2.2. AD Followup
A.2.2. 广告跟进

"AD Followup" is a generic substate indicating that the shepherding AD has the action to determine the appropriate next steps. In particular, the appropriate steps (and the corresponding next state or substate) depend entirely on the nature of the issues that were raised and can only be decided with active involvement of the shepherding AD.

“AD Followup”是一个通用子状态,表示牧羊AD有权确定适当的后续步骤。特别是,适当的步骤(以及相应的下一个状态或子状态)完全取决于提出的问题的性质,并且只能在牧羊人广告的积极参与下决定。

Examples include:

例子包括:

- If another AD raises an issue, the shepherding AD may first iterate with the other AD to get a better understanding of the exact issue. Or, the shepherding AD may attempt to argue that the issue is not serious enough it to bring to the attention of the authors/WG.

- 如果另一个广告提出了问题,牧羊人广告可能会首先与另一个广告进行迭代,以更好地了解确切的问题。或者,牧羊人广告可能试图辩称该问题不够严重,不足以引起作者/工作组的注意。

- If a documented issue is forwarded to a WG, some further iteration may be needed before it can be determined whether a new revision is needed or whether the WG response to an issue clarifies the issue sufficiently.

- 如果将记录的问题转发给工作组,则可能需要进一步迭代,然后才能确定是否需要新的修订版本,或者工作组对问题的响应是否充分澄清了问题。

- When a new revision appears, the shepherding AD will first look at the changes to determine whether they believe all outstanding issues have been raised satisfactorily, prior to asking the ADs who raised the original issues to verify the changes.

- 当新版本出现时,在要求提出原始问题的广告核实变更之前,指导广告将首先查看变更,以确定他们是否认为所有未决问题都已令人满意地提出。

A.2.3. External Party
A.2.3. 外方

The document is awaiting review or input from an external party (i.e., someone other than the shepherding AD, the authors, or the WG). See the "note" field for more details on who has the action.

该文件正在等待外部方(即除牧羊人广告、作者或工作组以外的其他人)的审查或输入。请参阅“备注”字段以了解有关谁拥有该操作的更多详细信息。

A.2.4. Revised ID Needed
A.2.4. 需要修改身份证

An updated I-D is needed to address the issues that have been raised.

需要更新I-D以解决提出的问题。

Author's Address

作者地址

Ed Juskevicius TrekAhead PO Box 491, Carp, ON CANADA

Ed Juskevicius TrekAhead邮政信箱491号,加拿大卡普

   EMail: edj.etc@gmail.com
        
   EMail: edj.etc@gmail.com