[要約] RFC 4858は、ワーキンググループの最終呼び出しから公開までのドキュメントシェパーディングに関するガイドラインです。このRFCの目的は、効果的なドキュメントシェパーディングプロセスを提供し、RFCの公開に向けたスムーズな移行を支援することです。
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）The IETF Trust（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 Process」または「Proto」と呼ばれるそのような実験の1つ（「プロセスとツール」または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チームによって開発および操縦された方法論は、主要な文書羊飼いとしてワーキンググループの椅子または秘書に焦点を当てています。このドキュメント羊飼いプロセスの主な目的は、責任あるエリアディレクターとドキュメントシェパードとのパートナーシップを可能にすることにより、ドキュメント処理スループットとドキュメントの品質を改善することです。特に、このパートナーシップには、ドキュメントシェパードに敵対するという明確な目標がありますが、同時に、責任あるエリアディレクターの責任を負っていたフォローアップ作業の特定の部分を除外します。責任あるエリアディレクターには、従うべき数十または数十のドキュメントがありますが、ドキュメントシェパードには一度に数個しかありません。ワーキンググループレベルに責任を負わせることで、より多くの注意とよりタイムリーな対応を確保できます。
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.
したがって、ドキュメント羊飼いプロセスには、ワーキンググループの最後のコール後のすべてのドキュメント処理段階、つまりドキュメントの広告評価、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
o セクション3.1で説明されているように、公開が要求されたときに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で説明されているように、編集者、ワーキンググループ、および責任あるエリアディレクターの間の議論を管理します。
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評価中、セクション3.3で説明されているように、羊飼いのドキュメントに関連するすべてのIESGフィードバック（「ディスカッション」および「コメント」項目）をフォローアップします。
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.
羊飼いは、文書を前進させ続け、それについてレビューしてコメントする当事者と通信しなければなりません。羊飼いは、実質的な提案された変更について、ワーキンググループのコンセンサスを取得する必要があります。羊飼いは、文書とワーキンググループのリーダーであり、批判的かつ技術的な視点を維持しています。要約すると、羊飼いは、ワーキンググループの文書の責任中に彼または彼女が行ったように、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.
ドキュメントの羊飼いが行われる前に、文書のために単一のドキュメント羊飼いを特定する必要があります（彼または彼女はドキュメントシェパードの記事に命名されます）。多くの場合、椅子と責任あるエリアディレクターは、ワーキンググループが将来のすべての文書のプロトプロセスを採用することを決定します。その決定の後、椅子は、責任あるエリアディレクターと相談して、誰が特定の文書の文書羊飼いとして行動すべきかを決定します。これは通常、デフォルトでワーキンググループの椅子の1つです。責任あるエリアディレクターと協議して、椅子は、特定の文書の羊飼いとしてワーキンググループ秘書を任命することも決定する場合があります。ドキュメントシェパードは、羊飼い文書の編集者であってはなりません。
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.
羊飼いのプロセス全体で、文書羊飼いの役割は1人によって満たされることを意図しています。ただし、文書の生涯において、文書羊飼いの役割が異なる人に再割り当てされる可能性がある場合に、状況が発生する場合があります。これが必要になる可能性がある状況を特定するのは、椅子と責任あるエリアディレクター次第であり、新しい文書羊飼いを任命するために相談してください。
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アーカイブの関連するエントリへのポインターは役立ちます）。ここでの目標は、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.
タスクの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、Internationalization、または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コンセンサスはどの程度固体ですか？それは少数の個人の強い同意を表していますか？
(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>.'
この文書の文書羊飼いは誰ですか？責任あるエリアディレクターは誰ですか？ドキュメントにIANAの専門家が必要な場合、「このドキュメントのレジストリの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事務局、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.
ドキュメントシェパードの連絡先情報は、Gen-Artチーム[Gen-Art]、エリア局、およびその他のレビューチームにとっても重要であるため、責任あるエリアディレクターに加えて、レビューに誰に対処するかを知ることができます。
The steps for document shepherding during AD Evaluation are as follows:
広告評価中のドキュメント羊飼いの手順は次のとおりです。
(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）で開始することにより、ドキュメントの改訂版で、広告評価中に見つけた問題が解決されることを確認します。
(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の最後の呼び出しを受け、広告が最後の呼び出し中に重要な問題が提起されたと結論付けた場合、ステップ（2.B）から（2.H）を適用して最後の呼び出し問題に対処する必要があります。これには、責任あるエリアディレクターが文書に提示する必要があります。
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種類の発言を提出できます。アイテムの議論とコメント項目です。議論は、ドキュメントの承認プロセスを解決するまでブロックします。コメントはありません。このセクションでは、Shepherdが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 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.a）IESG電話会議に至るまで、ドキュメントシェパードは、1つ以上の広告に代わって監督レビュアーからのドキュメントに関するメールを見ることができ、IDトラッカーに入力されたディスカッションアイテムのコピーを電子メールで送信しました。ドキュメントシェパードは、すぐにそれらを提起した広告との議論とコメントの解決に取り組み始め、責任あるエリアディレクターを電子メール交換にコピーして、電話会議中にアクティビティをサポートできるようにします。監督のレビューを扱う際、羊飼いは、これらの総局が報告する広告に、これらの広告が解決する必要があるレビューコメントを検討することを確認する必要があります。
(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フォローアップ「、羊飼いは電子メールを受け取ります。「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トラッカーを照会して、文書に対して提起された残りのディスカッション項目を収集し、コメントします。ドキュメントシェパードはこれらのアイテムを分析し、それらを配置した広告との連絡を初期化します。責任あるエリアディレクターは、アクティブディスカッションまたはコメント項目に関連するすべての通信でコピーする必要があります。これは、責任あるエリアディレクターを解決に向けた重要な道に置くのではなく、議論の状態について彼または彼女に通知する必要があります。
+-------+ +-------+ +-------+
| (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.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処理中に蓄積されたドキュメントへの変更について、ドキュメントエディターとワーキンググループにディスカッションとコメント項目を伝えます。変更が実質的になる場合、文書シェパードは、他の段階でのように、責任あるエリアディレクターと協議して、ワーキンググループのコンセンサスまたは場合によっては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）文書シェパードが改訂された文書が評価コメントに扱っていることに満足している場合、彼または彼女は、責任あるエリアディレクターとディスカッションアイテムを提起し、コメントした広告に決議を伝えます。
(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
議論がそれを提起した広告または責任あるエリアディレクターの満足度まで解決されなかった場合、2つの可能性が存在します。（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) 繰り返し明確化と議論をしたにもかかわらず、それを提起した広告との議論の解決について進展がない場合、責任あるエリアディレクターは、文書の継続的な羊飼いを引き継ぐべきです。このような状況は、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）責任あるエリアディレクターは、文書を「承認された - 送信する発表」に移動します。改訂されたドキュメントの変更が重要であると彼または彼女が重要であると判断した場合、新しい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によるアクションを必要とする考慮事項が含まれます。文書シェパードは、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のアクションを羊飼いするタスクはしばしば見落とされがちですが、他のすべてのドキュメントがShepherdが管理したドキュメントレビューと同様に調整して管理することも重要です。それらと同様に、ドキュメントシェパードは、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エディターに送られ、現在、文書Shepherd（発表の記事で識別されています）は、技術的な出版を通じて文書をシェパードし続けています。RFCエディターは現在、著者に多くの種類のリクエストを行っており、Shepherdと責任あるエリアディレクターを文書化しています。ドキュメントシェパードは、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エディターリクエストの種類には、次のものが含まれます。ドキュメントソースのリクエスト（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.
ドキュメントシェパードの記事は、ジョン・クレンシンのアイデアに由来しています。トーマス・ナルテンとマーガレット・ワッサーマンは、インターネットエリア全体にそれを実装し、そのテンプレートは今日使用されているバージョンの基礎でした。
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に含まれるDraft-avt-avt-rtp-midi-formatのドラフト-ietf-avt-rtp-midi-formatの元のドキュメントアナウンスの記事を書きました。David Blackは、付録A.2に含まれるDraft-IiTf-IMSS-IP-Over-Fibre-Fibre-Fibre-Fibre-Channelの元の文書発表の記事を書きました。両方のオリジナルの発表は、書かれてからドキュメントアナウンスの記述テンプレートの変更を反映するように変更されました。
Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call.
フランク・エラーマンとオラファー・グドムンソンは、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、「標準の初期の配分追跡コードポイント」、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インターネットドラフトトラッカー」、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/ Reviewgidelines.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.
この付録には、ドキュメントアナウンスの記事の2つの例が含まれています。「プロトコルアクション」や「ドキュメントアクション」などの件名を備えたより多くの例は、IETF-Announceメーリングリストアーカイブに記載されています。
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ペイロード形式（楽器デジタルインターフェイス）の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 Manufacturers Associationによってレビューされており、彼らのコメントが対処されています。
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.
マグナス・ウェスターランドとコリン・パーキンスは、共同でこの文書を羊飼いしました。Allison Mankinは、IESGのドキュメントをレビューしました。これには、メディアタイプの編集者との慎重なレビューを含め、2006-01-08にリクエストされたIETFタイプリストレビューと並行して問題が発生しました。
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パケットのカプセル化を指定しています。このドキュメントは、Fiberチャネルネットワーク上のIPv6 Link-LocalアドレスとStatelestely Autoconfigured IPv6アドレスを形成する方法と、ファイバーチャネルネットワーク上のIPv4アドレス解像度を実行するメカニズムも指定しています。このドキュメント（RFCとして公開されている場合）Obsoletes 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（Fiber Channel Standards組織）のファイバーチャネル専門家によってレビューされています。このドキュメントには、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 2625）およびファイバーチャネル（RFC 3831）を介して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.
プロトコルは、David L. Black（WGチェア）によってIESGのためにレビューされています。Bert Wijnenは、IESGのこのドキュメントをレビューしました。さらに、ブライアン・ハーバーマンは、マーガレット・ワッサーマンを介してWG-Chair（David Black）が要求したように、INTエリアのレビューを行っています。
Authors' Addresses
著者のアドレス
Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden
Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden
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 USA
Phone: +1 541 346 1747
EMail: dmm@1-4-5.net
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
Lars Eggert Nokia Research Center P.O.Box 407 Nokia Group 00045フィンランド
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。