Network Working Group H. Levkowetz
Request for Comments: 4858 Ericsson
Category: Informational D. Meyer
Cisco/University of Oregon
L. Eggert
Nokia
A. Mankin
May 2007
Network Working Group H. Levkowetz
Request for Comments: 4858 Ericsson
Category: Informational D. Meyer
Cisco/University of Oregon
L. Eggert
Nokia
A. Mankin
May 2007
Document Shepherding from Working Group Last Call to Publication
工作组最后一次发布呼吁中的文件管理
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role.
本文档描述了旨在改进和促进IETF文档流处理的方法。它规定了一套程序，根据该程序，工作组主席或秘书担任已提交给IESG出版的文件的主要文件保管人。在此之前，负责工作组的区域主任通常担任牧羊人的角色。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Process Description . . . . . . . . . . . . . . . . . . . . . 4
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5
3.2. Document Shepherding during AD Evaluation . . . . . . . . 9
3.3. Document Shepherding during IESG Evaluation . . . . . . . 10
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 13
5. Document Shepherding after IESG Approval . . . . . . . . . . . 14
6. When Not to Use the Document Shepherding Process . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18
A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Process Description . . . . . . . . . . . . . . . . . . . . . 4
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5
3.2. Document Shepherding during AD Evaluation . . . . . . . . 9
3.3. Document Shepherding during IESG Evaluation . . . . . . . 10
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 13
5. Document Shepherding after IESG Approval . . . . . . . . . . . 14
6. When Not to Use the Document Shepherding Process . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18
A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
Early in 2004, the IESG undertook several experiments aimed at evaluating whether any of the proposed changes to the IETF document flow process would yield qualitative improvements in document throughput and quality. One such experiment, referred to as the "PROTO process" or "PROTO" (because it was created by the "PROcess and TOols" or PROTO [PROTO] team), is a set of methodologies designed to involve working group chairs or secretaries more directly in their documents' approval life cycle. In particular, the PROTO team focused on improvements to the part of a document's life cycle that occurs after the working group and document editor have forwarded it to the IESG for publication.
2004年初，IESG进行了几项实验，旨在评估IETF文档流流程的任何拟议变更是否会在文档吞吐量和质量方面产生质的改进。其中一个实验被称为“PROTO流程”或“PROTO”（因为它是由“流程和工具”或PROTO[PROTO]团队创建的），是一套旨在让工作组主席或秘书更直接地参与其文件审批生命周期的方法。特别是，PROTO团队重点关注在工作组和文档编辑器将文档转发给IESG进行发布后，文档生命周期部分的改进。
By the end of 2004, the IESG had evaluated the utility of the PROTO methodologies based on data obtained through several pilot projects that had run throughout the year, and subsequently decided to adopt the PROTO process for all documents and working groups. This document describes this process.
到2004年底，IESG根据全年运行的几个试点项目获得的数据评估了PROTO方法的效用，随后决定对所有文件和工作组采用PROTO流程。本文档描述了此过程。
The methodologies developed and piloted by the PROTO team focus on the working group chair or secretary as the primary Document Shepherd. The primary objective of this document shepherding process is to improve document-processing throughput and document quality by enabling a partnership between the Responsible Area Director and the Document Shepherd. In particular, this partnership has the explicit goal of enfranchising the Document Shepherd while at the same time offloading a specific part of the follow-up work that has traditionally been responsibility of the Responsible Area Director. The Responsible Area Director has tens or many tens of documents to follow, while the Document Shepherd has only a few at a time. Flowing the responsibility to the working group level can ensure more attention and more timely response.
原型团队开发和试验的方法侧重于工作组主席或秘书作为主要文件。该文件管理流程的主要目标是通过使责任区域总监和文件管理人之间建立伙伴关系，提高文件处理吞吐量和文件质量。特别是，这种伙伴关系的明确目标是授予文件管理员的特许权，同时卸下传统上由责任区域总监负责的后续工作的特定部分。负责的区域主管有几十个或几十个文档要遵循，而文档管理员一次只有几个。将责任转移到工作组一级可以确保更多的关注和更及时的响应。
Consequently, the document shepherding process includes follow-up work during all document-processing stages after Working Group Last Call, i.e., during AD Evaluation of a document, during IESG Evaluation, and during post-approval processing by IANA and the RFC Editor. In these stages, it is the responsibility of the Document Shepherd to track and follow up on feedback received on a document from all relevant parties.
因此，文件管理流程包括工作组最后一次呼叫后所有文件处理阶段的后续工作，即文件的AD评估期间、IESG评估期间以及IANA和RFC编辑器的审批后处理期间。在这些阶段，文件管理员负责跟踪和跟进从所有相关方收到的文件反馈。
The Document Shepherd is usually a chair of the working group that has produced the document. In consultation with the Responsible Area Director, the chairs may instead decide to appoint the working group secretary as the responsible Document Shepherd.
文件管理员通常是编制文件的工作组主席。在与负责区域主任协商后，主席可决定任命工作组秘书为负责文件管理员。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
The document shepherding process consists of the following tasks:
文件管理过程包括以下任务：
o Providing the Document Shepherd Write-Up accompanying a document that is forwarded to the IESG when publication is requested, as described in Section 3.1.
o 如第3.1节所述，提供随文件一起提交给IESG的文件摘要，并在要求发布时提交给IESG。
o During AD Evaluation of the document by the Responsible Area Director, managing the discussion between the editors, the working group, and the Responsible Area Director, as described in Section 3.2.
o 如第3.2节所述，在负责区域主任对文件进行AD评估期间，管理编辑、工作组和负责区域主任之间的讨论。
o During an IETF Last Call, if performed for the shepherded document, following up on community feedback and review comments.
o 在IETF最后一次呼叫期间，如果对托管文档执行，则跟进社区反馈和审查意见。
o During IESG Evaluation, following up on all IESG feedback ("DISCUSS" and "COMMENT" items) related to the shepherded document, as described in Section 3.3.
o 在IESG评估期间，跟进所有IESG反馈（“讨论”和“评论”项目），如第3.3节所述。
o Following up on IANA and RFC Editor requests as described in Section 4 and Section 5.
o 按照第4节和第5节所述，跟进IANA和RFC编辑器请求。
The shepherd must keep the document moving forward, communicating about it with parties who review and comment on it. The shepherd must obtain the working group's consensus for any substantive proposed changes. The shepherd is the leader for the document and for the working group, and maintains a critical and technical perspective. In summary, the Document Shepherd continues to care for a shepherded document during its post-WG lifetime just as he or she has done while responsible for the document in the working group.
牧羊人必须继续推进文件，并与审查和评论文件的各方沟通。牧羊人必须就任何实质性的拟议变更取得工作组的共识。牧羊人是文件和工作组的领导者，并保持着批判性和技术性的观点。综上所述，文件保管人在其工作组之后的生命周期内继续保管保管的文件，就像他或她在工作组中负责该文件时所做的那样。
Before any document shepherding takes place, a single Document Shepherd MUST be identified for a document (he or she will be named in the Document Shepherd Write-Up). Frequently, the chairs and the Responsible Area Director will decide that the working group will adopt the PROTO process for all their future documents. After that decision, the chairs, in consultation with the Responsible Area Director, decide on who should act as Document Shepherd for any given document. This is typically and by default one of the chairs of the working group. In consultation with the Responsible Area Director,
在进行任何文件管理之前，必须为一份文件确定一名文件管理人（他或她将在文件管理人的书面报告中被命名）。通常，主席和负责的区域主任将决定工作组将为其未来的所有文件采用原型流程。在作出该决定后，主席与负责的区域主任协商，决定由谁担任任何给定文件的文件保管人。这通常是默认的工作组主席之一。与责任区域总监协商后，
the chairs MAY also decide to appoint the working group secretary as Document Shepherd for a given document. The Document Shepherd SHOULD NOT be an editor of the shepherded document.
主席还可决定任命工作组秘书为特定文件的文件保管人。文档守护者不应是被守护文档的编辑。
It is intended that the Document Shepherd role be filled by one person during the entire shepherding process. However, situations may occur when the Document Shepherd role may be reassigned to different persons during the lifetime of a document. It is up to the chairs and Responsible Area Director to identify situations when this may become necessary, and then consult to appoint a new Document Shepherd.
在整个管理过程中，文档管理者角色由一个人担任。但是，在文档的生命周期内，可能会将文档管理员角色重新分配给不同的人。由主席和负责区域的主管在必要时确定情况，然后协商指定新的文件。
It is important to note that the document shepherding process only applies to documents that are the product of a working group. It does not apply to documents that originate elsewhere. Additionally, Section 6 discusses other instances in which the document shepherding process does not apply.
必须指出的是，文件管理流程仅适用于工作组的文件。它不适用于源自其他地方的文件。此外，第6节讨论了文档管理过程不适用的其他实例。
When a working group decides that a document is ready for submission to the IESG for publication, it is the task of the Document Shepherd to complete a "Document Shepherd Write-Up" for the document.
当工作组决定一份文件准备好提交给IESG出版时，文件管理员的任务是完成该文件的“文件管理员撰写”。
There are two parts to this task. First, the Document Shepherd answers questions (1.a) to (1.j) below to give the Responsible Area Director insight into the working group process that applied to this document. Note that while these questions may appear redundant in some cases, they are written to elicit information that the Responsible Area Director must be aware of (to this end, pointers to relevant entries in the WG archive are helpful). The goal here is to inform the Responsible Area Director about any issues that may have come up in IETF meetings, on the mailing list, or in private communication that they should be aware of prior to IESG Evaluation of the shepherded document. Any significant issues mentioned in the questionnaire will probably lead to a follow-up discussion with the Responsible Area Director.
这项任务分为两部分。首先，本文件回答了以下问题（1.a）至（1.j），以使责任区总监深入了解适用于本文件的工作组流程。请注意，虽然这些问题在某些情况下可能显得多余，但编写这些问题是为了获取责任区域主管必须了解的信息（为此，指向工作组档案中相关条目的指针是有帮助的）。此处的目标是将IETF会议、邮件列表或私人通信中可能出现的任何问题告知负责区域主管，这些问题在IESG评估受监管文件之前应该知道。调查问卷中提到的任何重大问题都可能导致与责任区域主任进行后续讨论。
The second part of the task is to prepare the "Document Announcement Write-Up" that is input both to the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Item number (1.k) describes the elements of the Document Announcement Write-Up.
任务的第二部分是准备“文件公告撰写”，将其输入IESG Telecohat的投票和最终的IETF范围内的公告消息。项目编号（1.k）描述了文件公告撰写的要素。
Some examples of Document Announcement Write-Ups are included in Appendix A, and there are many more examples with subject lines such as "Protocol Action" and "Document Action" in the IETF-announce mailing list archive.
附录A中包含了一些文件公告撰写的示例，IETF公告邮件列表归档中还有更多主题行示例，如“协议行动”和“文件行动”。
The initial template for the Document Shepherd Write-Up is included below, but changes are expected over time. The latest version of this template is available from the IESG section of the IETF web site.
文档编写的初始模板包括在下面，但预计会随着时间的推移而发生更改。该模板的最新版本可从IETF网站的IESG部分获得。
(1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?
（1.a）谁是本文件的文件保管人？文件管理员是否亲自审查了该版本的文件，尤其是他或她是否认为该版本已准备好提交给IESG出版？
(1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
（1.b）主要工作组成员和主要非工作组成员是否对该文件进行了充分审查？文件是否对已执行的审查的深度或广度有任何顾虑？
(1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?
（1.c）文档是否担心文档需要从特定或更广泛的角度进行更多审查，例如，安全性、操作复杂性、熟悉AAA、国际化或XML的人员？
(1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.
（1.d）文件是否有责任区域总监和/或IESG应了解的与本文件相关的任何具体问题或疑虑？例如，他或她可能对文档的某些部分感到不舒服，或者担心是否真的需要它。无论如何，如果工作组已讨论了这些问题，并表示仍希望推进该文件，请在此详述这些关注事项。与本文件相关的知识产权披露是否已备案？如果是，请提供披露的参考资料，并总结工作组关于该问题的讨论和结论。
(1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
（1.e）本文件背后的工作组共识有多坚实？它是代表了少数人的强烈赞同，而其他人则保持沉默，还是工作组作为一个整体理解并同意它？
(1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.)
（1.f）是否有人威胁上诉或以其他方式表示极度不满？如果是，请在单独的电子邮件中向责任区域总监总结冲突区域。（由于此问卷已输入ID跟踪器，因此应在单独的电子邮件中。）
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.
是否满足所有需要的正式审查标准，如MIB医生、媒体类型和URI类型审查？如果文件未在第一页顶部注明其预期状态，请在此处注明预期状态。
(1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].
（1.h）文件是否将其引用分为规范性引用和信息性引用？是否存在未准备好推进或处于不明确状态的文件的规范性引用？如果存在此类规范性参考文件，完成这些文件的策略是什么？是否有[RFC3967]中所述的向下引用的规范性引用文件？如果是，请列出这些向下引用，以支持区域控制器在最后一次调用过程中为其提供支持[RFC3967]。
(1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?
（1.i）文件是否验证了文件的IANA考虑部分是否存在，并且与文件正文一致？如果文件指定了协议扩展，是否在适当的IANA注册中心请求保留？IANA注册处是否明确标识？如果该文件创建了一个新的登记册，它是否定义了登记册的拟议初始内容以及今后登记的分配程序？这是否为新的注册中心提供了一个合理的名称？见[RFC2434]。如果该文件描述了专家评审过程，该文件是否已与责任区域总监协商，以便IESG能够在IESG评估期间任命所需的专家？
(1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?
（1.j）文档Shepherd是否验证了以正式语言编写的文档部分（如XML代码、BNF规则、MIB定义等）是否在自动检查器中正确验证？
(1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
（1.k）IESG批准公告包括文件公告撰写。请提供这样一份文件，包括公告和书面报告。最近的例子可以在批准文件的“行动”公告中找到。批准公告包含以下部分：
Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.
技术总结相关内容通常可在文件摘要和/或简介中找到。如果没有，这可能表明摘要或导言中存在缺陷。
Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?
工作组摘要：工作组流程中是否有值得注意的内容？例如，是否存在关于特定点的争议，或者是否存在共识特别粗糙的决定？
Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted?
文档质量协议是否有现有的实现？是否有相当多的供应商表示了实施规范的计划？是否有值得特别提及的审阅者进行了彻底的审阅，例如，导致重大更改或得出文件没有实质性问题的结论？如果有MIB医生、媒体类型或其他专家评论，其过程是什么（简短）？在媒体类型审查的情况下，请求发布的日期是什么时候？
Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are <TO BE ADDED BY THE AD>.'
谁是本文件的文件管理员？谁是负责的区域主管？如果文件需要IANA专家，请插入“本文件中登记处的IANA专家<由AD添加>”
The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling.
文件管理员必须将文件管理员的书面报告发送给负责的区域总监和iesg-secretary@ietf.org以及发布文档的请求。文件保管人还应将整个文件保管人书面记录发送至工作组邮件列表。如果文件管理员认为信息可能被证明是敏感的，可能导致可能的上诉，或者是个人需要记录的，则应直接通过电子邮件发送给负责的区域总监，因为文件管理员的记录是在ID跟踪器中公开发布的。书面报告中的问题（1.f）涵盖了任何此类性质的材料，并规定了更为保密的处理方式。
The Document Shepherd Write-Up is entered into the ID Tracker [IDTRACKER] as a "Comment". The name and email address of the Document Shepherd are entered into the ID Tracker, currently as a "Brief Note" (this may change in the future). The email address of the Document Shepherd MUST also be added to the "State or Version Change Notice To" field (typically the email addresses of all working group chairs, authors, and the secretary will be added).
文档记录作为“注释”输入ID跟踪器[IDTRACKER]。文档的名称和电子邮件地址被输入到ID跟踪器中，当前作为“简要说明”（将来可能会更改）。文件的电子邮件地址也必须添加到“状态或版本更改通知”字段中（通常会添加所有工作组主席、作者和秘书的电子邮件地址）。
Entering the name and email of the Document Shepherd into the ID Tracker is REQUIRED to ensure that he or she will be copied on the email exchange between the editors, chairs, the IESG, the IESG secretariat, IANA, and the RFC Editor during the review and approval process. There are still manual steps required for these parties to
需要在ID跟踪器中输入文件管理员的姓名和电子邮件，以确保在审查和批准过程中，编辑、主席、IESG、IESG秘书处、IANA和RFC编辑之间的电子邮件交换中复制该管理员。这些缔约方仍然需要手动步骤来完成这些任务
ensure that they include the Document Shepherd, but it is hoped that in the future, automated tools will ensure that Document Shepherds (and others) receive necessary communications.
确保它们包括文档管理员，但希望将来，自动化工具将确保文档管理员（和其他人）收到必要的通信。
The contact information for the Document Shepherd is also important for the Gen-ART team [GEN-ART], area directorates, and other review teams, so they can know to whom to address reviews, in addition to the Responsible Area Director.
文件管理员的联系信息对于Gen ART团队【Gen-ART】、地区总监和其他审查团队也很重要，因此他们可以知道除了负责的地区总监之外，还应该向谁进行审查。
The steps for document shepherding during AD Evaluation are as follows:
AD评估过程中的文档引导步骤如下：
(2.a) The Responsible Area Director reads, evaluates, and comments on the document, as is the case when not using the document shepherding process. If the Responsible Area Director determines that the document is ready for IESG Evaluation, he or she indicates this to the Document Shepherd and the document shepherding process continues as described in Section 3.3.
（2.a）责任区域主任阅读、评估和评论文件，如不使用文件管理流程。如果责任区域主管确定文件已准备好进行IESG评估，他或她将向文件保管员表明这一点，并按照第3.3节所述继续文件保管过程。
(2.b) If the Responsible Area Director has identified issues with a document that must be addressed before IESG Evaluation can commence, he or she sends a full evaluation to the Document Shepherd and SHOULD also enter the review into the ID Tracker.
（2.b）如果负责区域主任已确定在IESG评估开始前必须解决的文件问题，他或她将完整评估发送给文件管理员，并应将审查输入ID跟踪器。
(2.c) The Document Shepherd reads the AD Evaluation comments, making very certain that all comments are understood, so that it is possible to follow up on them with the editors and working group. If there is some uncertainty as to what is requested, this SHOULD be resolved with the Responsible Area Director.
（2.c）该文件阅读广告评价意见，确保所有意见都被理解，以便能够与编辑和工作组跟进。如果对请求的内容存在一些不确定性，则应与负责的区域主管一起解决。
(2.d) The Document Shepherd sends the AD Evaluation comments to the editors and to the working group mailing list, in order to have a permanent record of the comments. It is RECOMMENDED that the Document Shepherd solicit from the editors an estimate on when the required changes will be completed and a revised document can be expected. Working groups that use issue tracking SHOULD also record the issues (and eventually their resolution) in their issue tracker.
（2.d）文件管理员将广告评价意见发送给编辑和工作组邮件列表，以便永久记录这些意见。建议该文件向编辑征求关于何时完成所需更改的估计，并预计将有一份修订的文件。使用问题跟踪的工作组还应在问题跟踪程序中记录问题（以及最终的解决方案）。
(2.e) During the production of a revised document that addresses the AD Evaluation comments, it is RECOMMENDED that the editors keep a list showing how each comment was addressed and what the revised text is. It is RECOMMENDED that this list be forwarded to the Responsible Area Director together with the revised document.
（2.e）在编制涉及广告评价意见的修订文件期间，建议编辑保留一份清单，说明如何处理每项意见以及修订文本是什么。建议将该清单连同修订后的文件一起提交给责任区总监。
(2.f) In the event that the editors or working group disagrees with a comment raised by the Responsible Area Director or has previously considered and dismissed the issue, the Document Shepherd MUST resolve the issue with the Responsible Area Director before a revised document can be submitted.
（2.f）如果编辑或工作组不同意负责区域主任提出的意见，或之前考虑并驳回了该问题，则文件管理员必须在提交修订文件之前与负责区域主任解决该问题。
(2.g) The Document Shepherd iterates with the editors (and working group, if required) until all outstanding issues have been resolved and a revised document is available. At this point, the Document Shepherd notifies the Responsible Area Director and provides him or her with the revised document, the summary of issues, and the resulting text changes.
（2.g）该文件将与编辑（以及工作组，如有需要）反复讨论，直到所有未决问题得到解决，并有一份修订后的文件可用。此时，文件管理员通知责任区域总监，并向其提供修订后的文件、问题摘要以及由此产生的文本更改。
(2.h) The Responsible Area Director verifies that the issues he or she found during AD Evaluation are resolved in the revised version of the document by starting the process described in this section at step (2.a).
（2.h）负责区域主任通过在步骤（2.a）中启动本节所述流程，验证其在AD评估期间发现的问题在修订版文件中得到解决。
(2.i) If the document underwent an IETF Last Call and the AD concludes that significant issues were raised during the Last Call, then steps (2.b) through (2.h) need to be applied addressing the Last Call issues. This requires the Responsible Area Director to present to the Document Shepherd those Last Call issues raised only to the IESG.
（2.i）如果文件经历了IETF最后一次调用，且AD认为在最后一次调用期间提出了重大问题，则需要应用步骤（2.b）至（2.h）解决最后一次调用问题。这要求责任区域总监向文件管理员提交仅向IESG提出的最后一次通话问题。
During IESG Evaluation of a document, ADs can bring forward two kinds of remarks about a document: DISCUSS items and COMMENT items. A DISCUSS blocks a document's approval process until it has been resolved; a COMMENT does not. This section details the steps that a Document Shepherd takes to resolve any DISCUSS and COMMENT items brought forward against a shepherded document during IESG Evaluation.
在IESG评估文档时，ADs可以对文档提出两种注释：讨论项和注释项。讨论会阻止文档的审批流程，直到解决该问题；评论并不重要。本节详细介绍了在IESG评估期间，文档管理员为解决针对托管文档提出的任何讨论和评论项目而采取的步骤。
Note that DISCUSS and COMMENT items are occasionally written in a manner that makes their intent unclear. In these cases, the Document Shepherd SHOULD start a discussion with the ADs who brought the items up to clarify their intent, keeping the Responsible Area Director informed. If this fails to clarify the intent, the Responsible Area Director may need to work towards a clarification inside the IESG.
请注意，讨论和评论项目的书写方式有时会使其意图不明确。在这些情况下，文档管理员应与提出项目的广告进行讨论，以澄清其意图，并随时通知负责的区域总监。如果这未能澄清意图，负责的区域主管可能需要在IESG内部进行澄清。
(3.a) Leading up to the IESG conference call, the Document Shepherd may see emails about the document from directorate reviewers on behalf of one or more ADs and also emailed copies of DISCUSS and COMMENT items entered into the ID Tracker. The Document Shepherd SHOULD immediately begin to work on resolving DISCUSS and COMMENT items with the ADs who have raised them, keeping the Responsible Area Director copied on
（3.a）在IESG电话会议之前，文件保管人可能会看到董事会审查人员代表一个或多个ADs发送的有关文件的电子邮件，以及输入ID跟踪器的讨论和评论项目的电子邮件副本。文档管理员应立即开始与提出讨论和评论的广告一起解决讨论和评论项目，并抄送负责的区域总监
the email exchange, so that he or she is able to support the activity during the conference call. When dealing with directorate reviews, the Document Shepherd MUST involve the ADs to whom these directorates report to ensure that these ADs consider the review comments that need resolving.
电子邮件交换，以便他或她能够在电话会议期间支持活动。在处理董事会评论时，牧羊人的文件必须涉及这些董事会报告的广告，以确保这些广告考虑需要解决的评论意见。
(3.b) Immediately following the conference call, when the document changes state from the "IESG Evaluation" state to one of the states requiring Document Shepherd action, e.g., "IESG Evaluation: Revised ID Needed" or "IESG Evaluation: AD Followup", the Document Shepherd will receive email. A state of "AD Followup" typically signifies the Responsible Area Director's hope that a resolution may be possible through a continued discussion or (more usually) through a small set of changes as "Notes to the RFC Editor".
（3.b）在电话会议之后，当文件状态从“IESG评估”状态更改为需要文件管理员采取行动的状态之一时，例如，“IESG评估：需要修改ID”或“IESG评估：AD跟进”，文件管理员将收到电子邮件。“广告跟进”状态通常表示责任区总监希望通过持续讨论或（更常见的是）通过“RFC编辑注意事项”等一系列小改动来解决问题。
Note that there may be very exceptional cases when DISCUSS items are registered after an IESG conference call. In these cases, the AD who has raised the DISCUSS MUST notify the Document Shepherd about it. (The notification facility in the ID Tracker is very convenient for this purpose and also for the cases where the DISCUSS and COMMENT items are updated after they are partially resolved.)
请注意，在IESG电话会议后注册讨论项目时，可能会出现非常特殊的情况。在这些情况下，提出讨论的广告必须通知文档管理员。（ID跟踪器中的通知功能非常方便用于此目的，也适用于讨论和评论项目在部分解决后更新的情况。）
(3.c) The Document Shepherd then queries the ID Tracker to collect the remaining DISCUSS and COMMENT items raised against the document. The Document Shepherd analyzes these items and initializes contact with the ADs who have placed them. The Responsible Area Director MUST be copied on all correspondence related to active DISCUSS or COMMENT items. This does not place the Responsible Area Director in the critical path towards a resolution, but should keep him or her informed about the state of the discussion.
（3.c）文档管理员然后查询ID跟踪器，以收集针对文档提出的其余讨论和评论项目。文档Shepherd分析这些项目并初始化与放置这些项目的广告的联系。所有与积极讨论或评论项目相关的信函必须抄送责任区域总监。这不会使责任区域主任处于解决问题的关键路径上，但应让他或她随时了解讨论情况。
+-------+ +-------+ +-------+
| (3.b) | -----------> | (3.c) | ------------> | (3.d) |
+-------+ Comments +-------+ Comments +-------+
collected /|\ | understood
| |
| | Comments not fully understood
| | (Further AD/Document Shepherd
| | discussion required)
+---+
+-------+ +-------+ +-------+
| (3.b) | -----------> | (3.c) | ------------> | (3.d) |
+-------+ Comments +-------+ Comments +-------+
collected /|\ | understood
| |
| | Comments not fully understood
| | (Further AD/Document Shepherd
| | discussion required)
+---+
(3.d) The Document Shepherd then coordinates the resolution of DISCUSS and COMMENT items and builds a consistent interpretation of the comments. This step is similar to much of the process described in Section 3.2.
（3.d）然后，文件管理员协调讨论和评论项目的解决方案，并对评论建立一致的解释。该步骤与第3.2节中描述的许多过程类似。
+-------+ +-------+
| (3.c) | ---------------> | (3.d) |
+-------+ Consistent +-------+
/|\ interpretation |
| | Further AD/Document Shepherd
| | discussion required
+--------------------------+
+-------+ +-------+
| (3.c) | ---------------> | (3.d) |
+-------+ Consistent +-------+
/|\ interpretation |
| | Further AD/Document Shepherd
| | discussion required
+--------------------------+
(3.e) The Document Shepherd then communicates the DISCUSS and COMMENT items to the document editors and the working group, alerting them of any changes to the document that have accumulated during IESG processing, such as "Notes to the RFC Editor". If any changes will be substantive, the Document Shepherd, in consultation with the Responsible Area Director, as during other stages, MUST confirm working group consensus or sometimes even IETF consensus.
（3.e）然后，文件管理员将讨论和评论项目传达给文件编辑和工作组，提醒他们在IESG处理过程中积累的任何文件更改，如“RFC编辑注意事项”。如果有实质性的变更，则与其他阶段一样，文件管理员必须与责任区域主任协商，确认工作组共识，有时甚至IETF共识。
(3.f) After the editors resolve the DISCUSS and COMMENT items, the Document Shepherd reviews the resulting new version of the document, which will be a revised document, a set of "Notes to the RFC Editor", or both, using his or her technical expertise to ensure that all raised DISCUSS and COMMENT issues have been resolved.
（3.f）编辑解决讨论和评论项目后，文件管理员将使用其技术专业知识审查文件的最终新版本，即修订文件、一套“RFC编辑须知”，或两者兼而有之，以确保所有提出的讨论和评论问题得到解决。
Note that the Document Shepherd MAY also suggest resolutions to DISCUSS and COMMENT items, enter them into an issue tracker, or perform other steps to streamline the resolution of the evaluation comments. It is very important to resolve the comments in a timely way, while the discussion is current for everyone involved.
请注意，文档管理员还可以建议讨论和评论项目的解决方案，将其输入问题跟踪程序，或执行其他步骤以简化评估意见的解决方案。及时解决意见是非常重要的，而讨论对所有相关人员来说都是最新的。
(3.g) When the Document Shepherd is satisfied that the revised document addresses the evaluation comments, he or she communicates the resolution to the Responsible Area Director and the ADs that had raised the DISCUSS and COMMENT items.
（3.g）当文件管理员确信修订后的文件处理了评估意见时，他或她将决议传达给负责的区域总监以及提出讨论和意见项目的ADs。
(3.h) Each AD who had raised a DISCUSS checks whether the communicated resolution addresses his or her items. If it does, the AD will clear the DISCUSS. If it does not, the AD notifies the Document Shepherd and adds information to the ID Tracker explaining why the DISCUSS was not resolved. The Document Shepherd informs the working group accordingly. (COMMENT items need not be checked and cleared, because they do not block the document, but ADs are encouraged to do so.)
（3.h）每个提出讨论的广告都会检查传达的决议是否涉及他或她的项目。如果是这样的话，广告将清除讨论。如果没有，广告会通知文档管理员，并向ID跟踪器添加信息，解释讨论未解决的原因。该文件据此通知工作组。（注释项不需要检查和清除，因为它们不会阻止文档，但鼓励广告这样做。）
If a DISCUSS was not resolved to the satisfaction of the AD that has raised it or the Responsible Area Director, two possibilities exist:
如果讨论的解决方案未能使提出讨论的广告或负责区域总监满意，则存在两种可能性：
(a) The process returns to step (3.d), or
(a) 该过程返回到步骤（3.d），或
(b) If no progress can be made on the resolution of the DISCUSS with the AD who has raised it, despite repeated clarifications and discussions, the Responsible Area Director should take over continued shepherding of the document. Such a situation may be indicative of larger issues that the PROTO process was not designed to handle.
(b) 如果在与提出讨论的AD讨论解决方案方面无法取得进展，尽管进行了多次澄清和讨论，负责的区域主任应继续指导文件。这种情况可能表明PROTO流程设计不用于处理更大的问题。
Once the process above has cleared all DISCUSS items, document shepherding continues with step (3.i).
一旦上述过程清除了所有讨论项目，文档管理将继续执行步骤（3.i）。
(3.i) The Responsible Area Director moves the document to the "Approved - Announcement to be sent" state in the ID Tracker. If he or she deems the changes to the revised document significant, there may be a new WG Last Call, or possibly a new IETF Last Call. The document goes through a new full IESG Evaluation process if there is a new IETF Last Call.
（3.i）负责区域主任将文件移动到ID跟踪器中的“已批准-待发送公告”状态。如果他或她认为对修订文件的更改很重要，可能会有新的工作组最后一次调用，或者可能会有新的IETF最后一次调用。如果有新的IETF最后一次调用，则该文档将经历一个新的完整IESG评估过程。
IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes the Document Shepherd must keep track of certain IANA actions to be completed by the IESG, such as ratifying the appointment of a designated Expert called for in the IANA Considerations. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list.
IETF工作组文件通常包括需要IANA采取行动的考虑因素，例如创建新的注册中心或向现有注册中心添加信息，可能是在咨询IESG指定的专家之后。有时，文件管理员必须跟踪IESG完成的某些IANA行动，例如批准IANA考虑中要求的指定专家的任命。IANA相关处理还可能包括指定类型的专家评审，例如在指定的ietf类型邮件列表上对提议的MIME媒体类型进行评审。
The IANA reviews IETF documents and requests responses at any or all of the following times: in response to IETF Last Call, during the IESG Evaluation review of the document, and at the time when the IANA performs actions in its web-based registry for the document, usually but not always after IESG approval of the document. More details of the IANA process and IETF interaction are found in [RFC2434].
IANA审查IETF文件并在以下任何或所有时间请求响应：响应IETF最后一次呼叫，在IESG对文件进行评估审查期间，以及IANA在其基于web的文件注册表中执行操作时，通常但不总是在IESG批准文件后。有关IANA过程和IETF交互的更多详细信息，请参见[RFC2434]。
At the time of this publication, RFC 2434 is under revision [RFC2434bis], and the updates are and will be of value to the Document Shepherd. Note that the Document Shepherd MUST determine (by individual review and consultation with others) what is the most recent and the most applicable IANA information and guidance for his or her document, be it the overall guidance, or external documents in his or her area, or in other areas. An example of an external document is [RFC4020].
在本出版物出版时，RFC 2434正在修订[RFC2434bis]，更新对本文件有价值。请注意，文件管理员必须（通过个人审查和与他人协商）确定其文件的最新和最适用IANA信息和指南，无论是总体指南，还是其所在领域或其他领域的外部文件。外部文档的一个示例是[RFC4020]。
Whenever an IANA request comes, during whatever phase of the shepherding process, the requester from IANA MUST ensure that the Document Shepherd and the Responsible Area Director both receive the request. The Document Shepherd is responsible for responding as rapidly as possible. He or she should discuss requests that introduce any possible concerns with the working group. The Document Shepherd and the Responsible Area Director may decide in consultation that an IANA request leads to a change that needs additional review or approval.
每当IANA请求出现时，在管理过程的任何阶段，IANA的请求者必须确保文件管理者和负责区域的主管都收到请求。文档管理员负责尽快做出响应。他或她应与工作组讨论提出任何可能关切的请求。文件管理员和责任区域总监可协商决定IANA请求导致需要额外审查或批准的变更。
In general, the Document Shepherd ensures that the IANA process completes, checks that the registry is correct and that the IANA Matrix (http://www.iana.org/numbers.html) is complete and consistent, and troubleshoots when all is not well. At the end of IANA processing, the Document Shepherd should be sure that the RFC Editor has acknowledged IANA conclusion, i.e., that the handoff has been made.
通常，文档管理器确保IANA过程完成，检查注册表是否正确，以及IANA矩阵是否正确(http://www.iana.org/numbers.html)是完整和一致的，并且在一切不好时进行故障排除。在IANA处理结束时，文档管理员应确保RFC编辑已确认IANA结论，即已完成移交。
In summary, the task of shepherding the IANA actions is often overlooked, but is as important to coordinate and manage as all the other document reviews the Document Shepherd has managed. As with those, the Document Shepherd contributes greatly to quality and timeliness of the document by effective and responsive shepherding of the IANA requests.
总之，指导IANA行动的任务经常被忽略，但协调和管理的重要性与指导文件管理的所有其他文件审查一样。与上述内容一样，文件管理员通过对IANA请求进行有效且响应迅速的管理，大大提高了文件的质量和及时性。
After the IESG Evaluation and resolution described in Section 3.3, the IESG approves the document, and the Responsible Area Director uses the ID Tracker to ask for any final changes to the Document Announcement Write-Up and for it to be issued. The Document Shepherd may have some edits for the Responsible Area Director, such as minor "Notes to the RFC Editor", and this is the time to consult and provide them.
在第3.3节所述的IESG评估和解决后，IESG批准该文件，责任区域总监使用ID跟踪器要求对文件公告撰写进行任何最终更改，并发布该文件。文件管理员可能会对责任区域总监进行一些编辑，如“RFC编辑注意事项”，现在是查阅和提供这些内容的时候。
The IESG approval announcement goes to the general community and to the RFC Editor, and now the Document Shepherd (identified in the Announcement Write-Up) continues to shepherd the document through its technical publication. The RFC Editor currently makes a number of types of requests to the authors, Document Shepherd and Responsible Area Director. The Document Shepherd SHOULD lead in responding to the RFC Editor and shepherd the document during the post-approval period to its publication.
IESG批准公告将发送给一般社区和RFC编辑，现在文档管理器（在公告撰写中确定）将继续通过其技术出版物管理文档。RFC编辑目前向作者、文档管理员和责任区主管提出多种类型的请求。文件保管员应带头响应RFC编辑器，并在批准后的发布期内保管文件。
The RFC Editor request types include: editorial queries about dangling or missing informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional
RFC编辑器请求类型包括：关于悬空或缺少信息性和规范性引用的编辑查询（好的指导应该尝试更早地捕捉这些，但它们会发生）；对文档源的请求（例如，XML或nroff）；偶尔的
technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group that prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure.
技术意见；并复制编辑以供作者审查和仔细审查（AUTH48）。对于后者，文件管理员应带头检查副本编辑在任何情况下都不会影响编写文件的工作组的一致措辞，并应加快多个合著者的检查。文件管理员还就审查任何作者对文件提出的批准后变更与责任区域总监进行协商。这些可能需要区域主任批准，如果不是完全协商一致的程序，通常需要提交工作组同意。
As in other phases of document shepherding, the Document Shepherd provides attentiveness and timeliness by serving as the informed representative of the document and helping its advancement and its integrity.
与文档管理的其他阶段一样，文档管理者通过充当文档的知情代表，帮助文档的进步和完整性，提供关注度和及时性。
As mentioned in Section 3, the Document Shepherd SHOULD NOT be an editor of the shepherded document. If this cannot be avoided by making another working group chair or secretary the Document Shepherd, the document shepherding process SHOULD NOT be used. There are several other cases in which the document shepherding process SHOULD NOT be used. These include:
如第3节所述，文档管理员不应是被管理员文档的编辑。如果无法通过让另一个工作组主席或秘书担任文件保管员来避免这种情况，则不应使用文件保管流程。在其他几种情况下，不应使用文档管理过程。这些措施包括：
1. Cases where the Document Shepherd is the primary author or editor of a large percentage of the documents produced by the working group.
1. 文件保管人是工作组编制的大部分文件的主要作者或编辑的情况。
2. Cases where the Responsible Area Director expects communication difficulties with the Document Shepherd (either due to experience, strong views stated by the Document Shepherd, or other issues).
2. 责任区域总监预计与文件管理员沟通困难的情况（由于经验、文件管理员陈述的强烈观点或其他问题）。
3. Cases where the working group itself is either very old, losing energy, or winding down (i.e., cases where it would not be productive to initiate new processes or procedures).
3. 工作组本身非常陈旧、失去活力或逐渐减少的情况（即启动新流程或程序不会产生成效的情况）。
Finally, note that other cases exist in which using the document shepherding process may not be productive. The final determination as to whether or not to use the document shepherding process is left to the Responsible Area Director. If the document shepherding process is not used, the Responsible Area Director acts as Document Shepherd, per the existing procedures of shepherding by Area Directors.
最后，请注意，在其他情况下，使用文档引导过程可能不会产生效果。是否使用文件管理流程的最终决定权留给负责的区域总监。如果未使用文件管理流程，则负责的区域总监将按照区域总监管理的现有程序担任文件管理人。
This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol-specific security issues.
本文件规定了IETF文件处理程序的变更。因此，它既不提出也不考虑特定于协议的安全问题。
This document creates no new requirements on IANA namespaces or other IANA requirements.
本文档对IANA名称空间或其他IANA要求没有新的要求。
This document is the product of the PROTO team, which includes the authors as well as Bill Fenner, Barbara Fuller, and Margaret Wasserman. Aaron Falk worked actively in PROTO until the start of 2006 and worked on earlier versions of the document.
该文件的作者包括Barbaret Wasner和Protofena Fuller。Aaron Falk在PROTO中一直积极工作到2006年初，并致力于文档的早期版本。
The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today.
谢泼德撰写的文件源于约翰·克林森的一个想法。Thomas Narten和Margaret Wasserman将其应用于整个互联网领域，他们的模板是今天使用的版本的基础。
Colin Perkins wrote the original Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format included in Appendix A.1. David Black wrote the original Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel included in Appendix A.2. Both original announcements have been modified to reflect changes to the Document Announcement Write-Up template since they were written.
Colin Perkins为附录A.1中包含的ietf avt rtp midi格式草案撰写了原始文件公告。David Black为附录A.2中包含的ietf imss ip over fibre channel草案撰写了原始文档公告。两个原始公告均已修改，以反映自编写以来对文档公告编写模板所做的更改。
Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call.
Frank Ellermann和Olafur Gudmundsson在IETF最后一次通话中建议对该文件进行改进。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020]Kompella，K.和A.Zinin，“早期IANA标准轨道代码点分配”，BCP 100，RFC 4020，2005年2月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004.
[RFC3967]Bush，R.和T.Narten，“澄清标准跟踪文件何时可以规范地引用较低级别的文件”，BCP 97，RFC 3967，2004年12月。
[RFC2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Work in Progress, March 2007.
[RFC2434bis]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，正在进行的工作，2007年3月。
[IDTRACKER] "The IETF Internet-Draft Tracker", Web Application: https://datatracker.ietf.org/, 2002.
[IDTRACKER]“IETF互联网草稿跟踪器”，网络应用程序：https://datatracker.ietf.org/, 2002.
[PROTO] "The IESG PROcess and TOols (PROTO) Team", Web Page: http://psg.com/~mrw/PROTO-Team, 2004.
[PROTO]“IESG过程和工具（PROTO）团队”，网页：http://psg.com/~mrw/原型团队，2004年。
[GEN-ART] "The General Area Review Team (GEN-ART)", Web Page: http://www.alvestrand.no/ietf/gen/ review-guidelines.html, 2005.
[GEN-ART]“一般区域审查小组（GEN-ART）”，网页：http://www.alvestrand.no/ietf/gen/ review-guidelines.html，2005年。
This appendix includes two examples of Document Announcement Write-Ups. Many more examples with Subject lines such as "Protocol Action" and "Document Action" can be found in the IETF-announce mailing list archive.
本附录包括两个文件公告撰写示例。更多主题行示例，如“协议操作”和“文档操作”，可在IETF公告邮件列表存档中找到。
A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format
A.1. ietf avt rtp midi格式草案的示例文档发布撰写
Technical Summary
技术总结
These documents define the RTP Payload format for MIDI (Musical Instrument Digital Interface), and additional guidelines on implementation specifically concerning the timing of reception and transmission for best performance in different applications. MIDI is a real-time media, which however is brittle to losses and errors. Therefore the RTP payload format defines recovery journals as a way of avoiding persistent audible errors, and discusses congestion control handling for these journals.
这些文件定义了MIDI（乐器数字接口）的RTP有效载荷格式，以及关于实现的附加指南，具体涉及在不同应用中实现最佳性能的接收和传输定时。MIDI是一种实时媒体，但容易丢失和出错。因此，RTP有效负载格式将恢复日志定义为避免持续可听错误的一种方法，并讨论了这些日志的拥塞控制处理。
The RTP payload for MIDI encodes the broad range of MIDI commands. The format is suitable for interactive applications (such as network musical performance) and content-delivery (such as file streaming).
MIDI的RTP有效载荷对广泛的MIDI命令进行编码。该格式适用于交互式应用程序（如网络音乐表演）和内容交付（如文件流）。
Working Group Summary
工作组摘要
There is consensus in the WG to publish these documents.
工作组一致同意发布这些文件。
Document Quality
文件质量
This RTP Payload format has been implemented during the development of the specification and successfully tested over an IP network between two remote sites, thus showing that the technical solution is successfully working. It has been reviewed by the MIDI Manufacturers Association and their comments have been addressed.
该RTP有效负载格式已在规范制定期间实施，并在两个远程站点之间的IP网络上成功测试，从而表明该技术解决方案正在成功运行。MIDI制造商协会已经对其进行了审查，并对他们的意见进行了讨论。
Personnel
全体人员
Magnus Westerlund and Colin Perkins jointly shepherded this document. Allison Mankin reviewed the document for the IESG, including a careful review with the editor of the media types, in parallel with ietf-types list review requested on 2006-01-08, which raised no issues.
Magnus Westerlund和Colin Perkins共同指导了这份文件。Allison Mankin审查了IESG的文件，包括与编辑一起仔细审查了媒体类型，与2006-01-08年要求的ietf类型列表审查同时进行，没有提出任何问题。
A.2. Example Document Announcement Write-Up for draft-ietf-imss-ip-over-fibre-channel
A.2. 光纤通道上ietf imss ip草案的示例文档发布撰写
Technical Summary
技术总结
This document specifies the encapsulation of IPv6, IPv4 and ARP packets over Fibre Channel. This document also specifies the methods for forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on Fibre Channel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document (when published as RFC) obsoletes RFC2625 and RFC3831.
本文档指定通过光纤通道封装IPv6、IPv4和ARP数据包。本文档还指定了在光纤通道网络上形成IPv6链路本地地址和无状态自动配置IPv6地址的方法，以及在光纤通道网络上执行IPv4地址解析的机制。本文件（作为RFC发布时）废除了RFC2625和RFC3831。
Working Group Summary
工作组摘要
This document has been reviewed by Fibre Channel experts in Technical Committee T11 (Fibre Channel standards organization) in addition to members of the IMSS WG. There is solid support for this document both in the WG and from T11.
本文件已由技术委员会T11（光纤通道标准组织）的光纤通道专家以及IMSS工作组成员审查。工作组和T11对本文件都有坚实的支持。
Document Quality
文件质量
This document replaces and consolidates two separate RFCs on IPv4 over Fibre Channel (RFC 2625) and IPv6 over Fibre Channel (RFC 3831). Most of its technical content is unchanged from those RFCs. The technical changes that have been made are primarily based on implementation experience.
本文档取代并整合了光纤通道IPv4（RFC 2625）和光纤通道IPv6（RFC 3831）上的两个单独的RFC。其大部分技术内容与RFC相同。所做的技术更改主要基于实施经验。
Personnel
全体人员
The protocol has been reviewed for the IESG by David L. Black (WG chair). Bert Wijnen has reviewed this document for the IESG. In addition, Brian Haberman has done a review for the INT Area as requested by WG-chair (David Black) via Margaret Wasserman.
David L.Black（工作组主席）已为IESG审查了该协议。Bert Wijnen为IESG审查了本文件。此外，Brian Haberman已根据工作组主席（David Black）通过Margaret Wasserman对INT领域进行了审查。
Authors' Addresses
作者地址
Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden
Henrik Levkowetz Torsgatan 71斯德哥尔摩S-113 37瑞典
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
Phone: +46 708 32 16 08
EMail: henrik@levkowetz.com
David Meyer 1225 Kincaid St Eugene, OR 97403 USA
David Meyer 1225 Kincaid St Eugene或美国97403
Phone: +1 541 346 1747
EMail: dmm@1-4-5.net
Phone: +1 541 346 1747
EMail: dmm@1-4-5.net
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
芬兰诺基亚集团00045诺基亚研究中心邮政信箱407
Phone: +49 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert
Phone: +49 50 48 24461
EMail: lars.eggert@nokia.com
URI: http://research.nokia.com/people/lars_eggert
Allison Mankin
埃里森·曼金
Phone: +1-301-728-7199
EMail: mankin@psg.com
URI: http://www.psg.com/~mankin
Phone: +1-301-728-7199
EMail: mankin@psg.com
URI: http://www.psg.com/~mankin
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。