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
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.
方法論を開発し、主要なドキュメントの羊飼いとしてワーキンググループの議長や書記のPROTOチームの焦点が操縦します。この文書シェパディングプロセスの主要な目的は、担当エリアディレクターと文献シェパードとの間のパートナーシップを可能にすることによって、文書処理のスループットと文書の品質を改善することです。具体的には、このパートナーシップは、同時に伝統的責任エリアディレクターの責任となっているフォローアップ作業の特定の部分の負荷を軽減しながら、文書シェパードをenfranchisingの明確な目標を持っています。ドキュメントシェパードが一度にわずか数を持っていながら、責任エリアディレクターは、数十あるいは従うべき文書の数十を持っています。ワーキンググループレベルに責任を流すことより注目を集め、よりタイムリーなレスポンスを確保することができます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
ドキュメントシェパードはライトアップパブリケーションが要求されたときに、3.1節で説明したように、IESGに転送された文書に添付の提供、O。
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.
セクション3.3で説明したように、すべてのIESGフィードバック（「DISCUSS」および「コメント」の項目）導いた文書に関連する、フォローアップ、IESG評価中に、O。
o Following up on IANA and RFC Editor requests as described in Section 4 and Section 5.
第4節と第5節で説明したようにIANAとRFC Editorの要求にフォローアップO。
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.
羊飼いは見直しとそれにコメント関係者とそれについての通信、前進文書を維持する必要があります。羊飼いは、任意の実質的な提案された変更のためのワーキンググループのコンセンサスを得なければなりません。羊飼いは、文書のためのワーキンググループのリーダーであり、かつ重要と技術的な視点を維持しています。要約すると、ドキュメントシェパードは、ワーキンググループでの文書に責任をしながら、彼または彼女が行っているだけのように、そのポストWGの存続期間中に導いた文書の世話をし続けています。
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.
任意のドキュメントシェパディングが行われる前に、単一のドキュメント・シェパードは、（彼または彼女がドキュメントシェパードライトアップで命名されます）文書のために特定されなければなりません。しばしば、椅子、責任エリアディレクターは、ワーキンググループは、すべての将来のドキュメントのためのPROTOプロセスを採用することを決定します。その決定した後、椅子は、責任エリアディレクターと相談して、任意の文書の文書羊飼いとして行動しなければならない人を決めます。これは、通常、デフォルトでワーキンググループの議長の一つです。責任エリアディレクターとの協議では、椅子にも与えられた文書の文書羊飼いとしてワーキンググループの書記を任命することを決定してもよいです。ドキュメント・シェパードは導いた文書の編集すべきではありません。
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.
この作業には2つの部分があります。まず、ドキュメント・シェパードは、この文書に適用されるワーキンググループのプロセスに責任エリアディレクターの洞察力を与えるために、以下の質問（1.A）（1.j）に応答します。これらの質問は、いくつかのケースでは冗長見えるかもしれないが、彼らは責任エリアディレクターが認識しなければならないことの情報を引き出すために書かれていることに注意してください（この目的のために、WGのアーカイブ内の関連するエントリへのポインタが役に立ちます）。ここでの目標は、メーリングリスト上、またはそれらが導いたドキュメントのIESG評価する前に知っておくべきプライベート通信では、IETFミーティングに出ている可能性のある問題について責任エリアディレクターを通知することです。アンケートに記載された任意の重要な問題は、おそらく責任エリアのディレクターとのフォローアップの議論につながります。
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.
タスクの第2の部分は、IESGのtelechatための投票および最終的な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-announceメーリングリストのアーカイブ内の「プロトコルアクション」と「ドキュメントアクション」などの件名で、より多くの例がありますされています。
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のWebサイトの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）文書は、キーWGメンバーから、キー非WGメンバーからの両方の適切な見直しがありましたか？ドキュメント・シェパードが実行されたレビューの深さや幅についての懸念を持っていますか？
(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が知っておくべきことは、この文書で特定の懸念や問題を持っていますか？例えば、おそらく彼または彼女は、文書の特定の部分と不快である、または実際にそれが必要であるかどうかの懸念を持っています。いずれにせよ、WGは、これらの問題を議論している場合、それはまだこれらの懸念ここでは、ドキュメント、詳細を前進させるために望んでいることを示しています。このドキュメントに関連するIPRの開示が提出されていますか？その場合は、開示への参照が含まれており、この問題に関するWGの議論と結論を要約してください。
(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）このドキュメントの後ろのWGコンセンサスはどのようにしっかりしていますか？それは他の人が静かであること、または全体としてWGを理解し、それに同意しないと、数人の強い同意を表していますか？
(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 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.
（1.g）ドキュメント・シェパードは個人的には、文書は、すべてのIDのニットを満たしていることを確認していますか？ （http://www.ietf.org/ID-Checklist.htmlとhttp://tools.ietf.org/tools/idnits/を参照してください。）定型のチェックが十分ではありません。このチェックは徹底的にする必要があります。文書は、そのような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は）ドキュメントシェパードなどの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?
ワーキンググループの概要は注目に値するWGの過程で何かありましたか？例えば、特定のポイントについての論争があったかコンセンサスが特に荒れた意思決定がありましたか？
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>.'
このドキュメントのドキュメント羊飼いである人事？責任エリアディレクターは誰ですか？文書（s）はIANAの専門家を必要とする場合は、「<ADによって追加されるように>この文書に記載されているレジストリのためにIANAエキスパート（複数可）。」を挿入
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 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.
審査の際にIDトラッカーに文書シェパードの名前とメールアドレスを入力すると、彼または彼女は編集者間のメール交換にコピーされることを保証する必要があり、椅子、IESG、IESG事務局、IANA、およびRFCエディタそして、承認プロセス。そこでは、ドキュメント・シェパードが含まれていることを保証するために、これらの当事者のために必要な手動手順はまだですが、将来的には、自動化ツールは、ドキュメントの羊飼い（と他の人が）必要な通信を受け取ることを保証することが期待されています。
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.
ドキュメント・シェパードの連絡先情報は、ジェン・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.
IESG評価を開始する前に、責任エリアディレクターが取り組まなければならない文書で問題を識別している場合（2.B）、彼または彼女は、ドキュメント・シェパードへの完全な評価を送信し、また、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）ドキュメント・シェパードは、すべてのコメントを理解していることを非常に特定すること、AD評価のコメントを読み込みます。要求されるものになど、いくつかの不確実性がある場合は、これは責任エリアのディレクターで解決する必要があります。
(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）ドキュメント・シェパードは、ADの評価、コメントの永久的な記録を持っているために、編集者やワーキンググループのメーリングリストにコメント送信します。ドキュメントシェパードは編集者から必要な変更が完了しますと、改訂された文書が期待できる場合に推定値を求めることが推奨されます。問題の追跡を使用するワーキンググループはまた、彼らの問題追跡に問題（そして最終的にはその解像度）を記録する必要があります。
(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）AD評価のコメントを扱う改訂文書の製作時には、編集者がそれぞれのコメントが取り上げられたかを示すリストを保持し、どのような修正されたテキストであることが推奨されます。このリストは改訂された文書と一緒に責任エリアディレクターに転送することが推奨されます。
(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）責任エリアディレクターは、彼または彼女はAD評価の際に見つかった問題は、ステップ（2.A）で、このセクションで説明するプロセスを開始することにより、文書の改訂版で解決されていることを確認します。
(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評価の際、広告が前方文書に関する発言の2種類をもたらすことができます：アイテムとCOMMENT項目を議論します。それが解決されるまでAブロックに文書の承認プロセスを議論します。 COMMENTはしていません。このセクションでは、ドキュメント・シェパードがいずれかが議論し、COMMENT項目が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.
アイテムを議論し、COMMENT注意が時折彼らの意図が不明確になり的に書かれています。これらのケースでは、ドキュメント・シェパードは責任エリアディレクターは知らさ維持、彼らの意図を明確にするためにアップアイテムをもたらしたのADとの議論を開始する必要があります。これは意図を明確にするために失敗した場合、責任エリアディレクターが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 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.
IESGの会議通話に至るまで（3.A）、ドキュメントシェパードは1つ以上の広告に代わって理事のレビュアーから文書についてのメールを見ても議論し、COMMENTアイテムのコピーを電子メールで送信するIDトラッカーを締結しました。ドキュメント・シェパードはすぐに議論し、解決に作業を開始すべきである彼または彼女は、会議通話中に活動をサポートすることができるように、メール交換にコピー責任エリアディレクターを保ち、それらを調達している広告をCOMMENT項目が。理事のレビューを扱う場合、ドキュメント・シェパードは、これらの総局は、これらの広告を解決する必要があるレビューコメントを検討することを保証するために、報告者に広告を伴わなければなりません。
(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）直ちに文書は、文書シェパードのアクションを必要とするなど、状態の1つに「IESG評価」状態から状態を変更し、会議通話、以下の「IESG評価：改訂IDが必要」または「IESG評価：ADフォロー」、ドキュメント・シェパードは、電子メールを受信します。 「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.)
(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）文書シェパードは、文書に対して惹起された残り議論しCOMMENTアイテムを収集するIDトラッカーを問い合わせます。ドキュメントシェパードは、これらの項目を分析し、それらを配置しているのADとの接触を初期化します。責任エリアディレクターはDISCUSSアクティブまたはCOMMENT項目に関連するすべての対応にコピーされなければなりません。これは、解決に向けクリティカルパスに責任エリアディレクターを置いていませんが、議論の状態に関する情報に彼を保つか、彼女の必要があります。
+-------+ +-------+ +-------+
| (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）文書シェパードは、次に議論しCOMMENTアイテムの解像度を調整し、コメントの一貫した解釈を構築します。このステップは、セクション3.2に記載されている方法の多くと同様です。
+-------+ +-------+
| (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）文書シェパードは、次いで、「RFC編集者への注意」としてIESG処理中に蓄積された文書への変更のそれらを警告、ドキュメントエディタとワーキンググループに議論しCOMMENT項目を通信します。変更が実質的になる場合は、ドキュメント・シェパードは、責任エリアディレクターと相談して、他のステージ中など、ワーキンググループのコンセンサスまたは時には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.
編集者が議論し、COMMENT項目を解決した後（3.f）、ドキュメント・シェパードは、彼を使用して、改訂された文書、「RFC編集者への注記」のセット、またはその両方される、文書の結果の新しいバージョンをレビューまたはすべての引き上げ議論し、COMMENT問題が解決されたことを確認するために彼女の技術的な専門知識。
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）は、彼または彼女は責任エリアディレクターと議論し、COMMENTアイテムを調達していた広告に解像度を伝えます。
(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）通信解像度が自分のアイテムを扱うかどうかのチェックをDISCUSS調達していた各AD。それがない場合は、ADはDISCUSSクリアされます。そうでない場合は、ADは、ドキュメントのシェパードを通知し、解決されなかった理由を説明する議論IDトラッカーに情報を追加します。ドキュメント・シェパードは、それに応じてワーキンググループを通知します。 （COMMENT項目がチェックされ、クリア、彼らは文書をブロックしていないので、しかし、広告がそうするよう奨励されている必要はありません。）
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
(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.
IDトラッカーの状態を - 「送信するお知らせ承認」（3.I）責任エリアディレクターにドキュメントを移動します。彼または彼女は重要な改訂文書への変更をと考えるならば、おそらく新しいWGラストコール、または新しい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ワーキンググループの文書は、多くの場合、IESG任命専門家に相談した後、おそらく、新しいレジストリを作成したり、既存のレジストリに情報を追加するなど、IANAの行動を、必要な考慮事項が含まれます。時には、ドキュメント・シェパードは、IANAの考慮事項のために呼ばれる指定された専門家の任命を批准として、IESGに完成する特定の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からの依頼者は、Documentシェパードと責任エリアディレクターは、両方の要求を受け取ることを保証しなければなりません。ドキュメント・シェパードは、可能な限り迅速に応答する責任があります。彼または彼女はワーキンググループを持つ可能性の懸念を紹介要求を議論する必要があります。ドキュメントシェパードと責任エリアディレクターは、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 Editorは、現在作者、ドキュメントシェパードと責任エリアディレクターへの要求の種類の数になります。ドキュメント・シェパードは、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 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.
RFC Editorの要求タイプは、次のとおり、有益で規範的な引用をダングリングまたは欠落についての社説のクエリを（良いシェパディングがこれらの以前のをキャッチしようとする必要がありますが、彼らが起こります）。文書ソース（例えば、XMLまたはnroffの）の要求。時折技術的なコメント。著者（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.
この文書は、著者だけでなく、ビルフェナー、バーバラ・フラー、およびマーガレットワッサーマンが含まPROTOチーム、の製品です。アーロンフォークは、2006年の開始までPROTOに積極的に協力し、ドキュメントの以前のバージョンに取り組みました。
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.
ドキュメントシェパードライトアップジョン・クレンシンによってアイデアで始まりました。トーマスNarten氏とマーガレットワッサーマンは、インターネット全体のエリアのためにそれを実装し、そのテンプレートは、今日使用されるバージョンの基礎となりました。
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.
コリン・パーキンスは、付録A.1に含まドラフト-IETF-AVT-RTP-MIDI形式のため、元の文書の発表ライトアップを書きました。デビッド・ブラックは、付録A.2に含まドラフト-IETF-IMSS-IPオーバー・ファイバー・チャネルのための原稿発表ライトアップを書きました。どちらもオリジナルの発表はそれらが書かれていたので、ドキュメントのお知らせライトアップテンプレートに変更を反映するように変更されました。
Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call.
フランクEllermannとオラフルグドムンソンは、IETFラストコール中にドキュメントの改善を示唆しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ジニン、 "標準化過程のコードポイントの初期の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]ブッシュ、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インターネットドラフトトラッカー"、Webアプリケーション：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）チーム"、Webページ：http://psg.com/~mrw/PROTO-Team、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）"、Webページ：http://www.alvestrand.no/ietf/gen/レビュー-guidelines.html、2005。
Appendix A. Example Document Announcement Write-Ups
付録A.例ドキュメントアナウンスライトアップ
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.
この付録では、ドキュメントのお知らせライトアップの2つの例を含んでいます。こうした「プロトコルアクション」と「ドキュメントアクション」などの件名でより多くの例がIETF-announceメーリングリストのアーカイブで見つけることができます。
A.1. Example Document Announcement Write-Up for draft-ietf-avt-rtp-midi-format
A.1。ドラフト-IETF-AVT-RTP-ミディフォーマットの例文書アナウンスライトアップ
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.
これらの文書を公開するWGでのコンセンサスがあります。
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ペイロードフォーマットは、仕様の開発中に実施し、成功したので、技術的な解決策が正常に動作していることを示す、2つのリモートサイト間の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.
マグヌスウェスターとコリンパーキンスが共同でこの文書を導きました。アリソンマンキンは何の問題を提起していない2006年1月8日に要求されたIETF-種類のリストの見直しと並行して、メディアタイプのエディタ、と慎重に検討を含め、IESGのための文書を検討しました。
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.
この文書では、IMSS WGのメンバーに加えて、技術委員会T11（ファイバチャネル標準化機構）でのファイバチャネルの専門家によって検討されています。このドキュメントのための固体支持体は、WGにし、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.
この文書は、ファイバチャネル（RFC 3831）を介してファイバチャネル（RFC 2625）およびIPv6上でIPv4の上に2つの別々の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.
プロトコルは、デビッドL.ブラック（WGいす）によってIESGのために検討されています。バートWijnenはIESGのために、この文書をレビューしています。マーガレットワッサーマンを経てWG議長（デビッド・ブラック）の要求に応じて加えて、ブライアンハーバーマンはINTエリアの見直しを行っています。
Authors' Addresses
著者のアドレス
Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden
ヘンリクLevkowetz Torsgatan 71ストックホルムS-113 37スウェーデン
Phone: +46 708 32 16 08 EMail: henrik@levkowetz.com
電話：+46 708 32 16 08 Eメール：henrik@levkowetz.com
David Meyer 1225 Kincaid St Eugene, OR 97403 USA
デビッド・マイヤー1225キンケードセントユージン、OR 97403 USA
Phone: +1 541 346 1747 EMail: dmm@1-4-5.net
電話：+1 541 346 1747 Eメール：dmm@1-4-5.net
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースEggertのノキア・リサーチセンター私書箱ボックス407ノキアグループ00045フィンランド
Phone: +49 50 48 24461 EMail: lars.eggert@nokia.com URI: http://research.nokia.com/people/lars_eggert
電話：+49 50 48 24461電子メール：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
電話：+ 1-301-728-7199 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。