RFC4858 日本語訳
4858 Document Shepherding from Working Group Last Call to Publication.H. Levkowetz, D. Meyer, L. Eggert, A. Mankin. May 2007. (Format: TXT=48572 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Levkowetzがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4858年のエリクソンカテゴリ: 情報のD.マイヤーシスコ/オレゴン大学L.エッゲルトノキアA.マンキン2007年5月
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).
IETFが信じる著作権(C)(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に提出されたドキュメントのための第一のDocument Shepherdとして役立つ1セットの手順を指定します。 この前に、ワーキンググループに責任があるAreaディレクターは見張ることの役割を伝統的にいっぱいにしました。
Levkowetz, et al. Informational [Page 1] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[1ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Process Description . . . . . . . . . . . . . . . . . . . . . 4
3.1. Document Shepherd Write-Up . . . . . . . . . . . . . . . . 5
3.2. Document Shepherding during AD Evaluation . . . . . . . . 9
3.3. Document Shepherding during IESG Evaluation . . . . . . . 10
4. Shepherding the Document's IANA Actions . . . . . . . . . . . 13
5. Document Shepherding after IESG Approval . . . . . . . . . . . 14
6. When Not to Use the Document Shepherding Process . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Example Document Announcement Write-Ups . . . . . . . 18
A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format . . . . . . . . . . . . . . 18
A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel . . . . . . . . . . 19
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 記述. . . . . . . . . . . . . . . . . . . . . 4 3.1を処理してください。 羊飼い記事. . . . . . . . . . . . . . . . 5 3.2を記録してください。 AD評価. . . . . . . . 9 3.3の間の見張ることを記録してください。 IESG評価. . . . . . . 10 4の間の見張ることを記録してください。 ドキュメントのIANA動作. . . . . . . . . . . 13 5を見張ります。 IESG承認. . . . . . . . . . . 14 6の後の見張ることを記録してください。 過程. . . . . . . 15 7を守って、いつドキュメントを使用しませんか? セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 16 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 16 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 17 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 17付録A.例のドキュメント発表記事. . . . . . . 18A.1。 草稿ietf-avt-rtpミディ形式.18A.2において、Document Announcement Write上がっている例。 草稿ietf-imss-ip過剰繊維チャンネル.19において、Document Announcement Write上がっている例
Levkowetz, et al. Informational [Page 2] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[2ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
1. Introduction
1. 序論
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ドキュメント流れの過程への変更案のどれかがドキュメントスループットと品質における質的改善をもたらすかどうか評価するのを目的とされたいくつかの実験を引き受けました。 「プロトの過程」か「プロト」(それが「過程とツール」によって作成されたか、またはプロト[プロト]が組になるので)と呼ばれたそのような実験の1つは彼らのドキュメントの承認のライフサイクルにより直接ワーキンググループいすか秘書にかかわるように設計された1セットの方法論です。 特に、プロトチームはワーキンググループとドキュメントエディタが公表のためにそれを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は、年間経営してい続けていたいくつかの試験計画を通して得られたデータに基づくプロト方法論に関するユーティリティを評価して、次に、すべてのドキュメントとワーキンググループのためにプロトの過程を採用すると決めました。 このドキュメントはこの過程について説明します。
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.
プロトチームによって開発されて、操縦された方法論は第一のDocument Shepherdとしてワーキンググループいすか秘書に焦点を合わせます。 過程を守るこのドキュメントの主目的はResponsible AreaディレクターとDocument Shepherdとのパートナーシップを可能にすることによって文書処理スループットとドキュメント品質を改良することです。 特に、このパートナーシップは同時に伝統的にResponsible Areaディレクターの責任である事後確認作業の特定の部分を積み下ろす間、Document Shepherdを解放するという明確な目標を持っています。 Responsible Areaディレクターには、10か従う多くの10通のドキュメントは、あります、Document Shepherdでは、一度に、ほんのいくつかがありますが。 流れて、ワーキンググループレベルへの責任は、より多くの注意と、よりタイムリーな応答を確実にすることができます。
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.
その結果、過程を守るドキュメントはすなわち、作業部会Last Callの後のすべての文書処理ステージ、ドキュメントのAD Evaluation、IESG Evaluation、およびIANAとRFC Editorによるポスト承認の処理の間、事後確認作業を含んでいます。 これらの段階では、それはドキュメントの上にすべての関係者から受け取られたフィードバックで追跡して、追求するDocument Shepherdの責任です。
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.
通常、Document Shepherdはドキュメントを製作したワーキンググループのいすです。 Responsible Areaディレクターとの相談では、いすは、代わりにワーキンググループの秘書を責任があるDocument Shepherdに任命すると決めるかもしれません。
Levkowetz, et al. Informational [Page 3] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[3ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
3. Process Description
3. プロセス記述
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 公表を要求するとき、Document Shepherd Write上がっている伴走にドキュメントを提供して、それをIESGに送ります、セクション3.1で説明されるように。
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で説明されるようにエディタと、ワーキンググループと、Responsible Areaディレクターとの議論を管理するResponsible AreaディレクターによるドキュメントのAD Evaluationの間。
o During an IETF Last Call, if performed for the shepherded
document, following up on community feedback and review comments.
o IETF Last Callの間、見張られたドキュメントのために実行されるなら、共同体フィードバックとレビューのときに追求するのはコメントします。
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 Evaluationの間、すべてのIESGフィードバック(項目について「議論し」て、「論評する」)で追求するのは見張られたドキュメントに関連しました、セクション3.3で説明されるように。
o Following up on IANA and RFC Editor requests as described in
Section 4 and Section 5.
o IANAとRFC Editorでは、セクション4で説明される要求とセクション5を追求します。
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.
羊飼いはそれの論評するパーティーとコメントでそれについて話し合って、前方へ動くドキュメントを保管しなければなりません。 羊飼いはどんな実質的な変更案に関するワーキンググループのコンセンサスも得なければなりません。 羊飼いは、ドキュメントとワーキンググループのリーダーであり、批判的で技術的な見解を維持します。 概要では、ワーキンググループにおいてドキュメントに責任がありますが、ちょうどその人がしたようにDocument Shepherdはポスト-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,
どんなドキュメントの見張ることが行われる前に、ドキュメントのために独身のDocument Shepherdを特定しなければなりません(その人はDocument Shepherd Write上がるところで命名されるでしょう)。 頻繁に、いすとResponsible Areaディレクターは、ワーキンググループがそれらのすべての将来のドキュメントのためにプロトの過程を採用すると決めるでしょう。 その決定の後に、Responsible Areaディレクターとの相談では、いすは、だれが何か与えられたドキュメントのためのDocument Shepherdとして務めるべきであるかを決めます。 これは通常とデフォルトでそうです。ワーキンググループのいすのひとり。 Responsible Areaディレクターとの相談で
Levkowetz, et al. Informational [Page 4] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[4ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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.
また、いすは、与えられたドキュメントのためのDocument Shepherdにワーキンググループの秘書を任命すると決めるかもしれません。 Document Shepherd SHOULD NOT、見張られたドキュメントのエディタになってください。
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.
Document Shepherdの役割が全体の見張ることの過程の間1人の人によっていっぱいにされることを意図します。 しかしながら、Document Shepherdの役割がドキュメントの生涯異なった人々に再選任されるとき、状況は起こるかもしれません。 これが必要になるかもしれないなら状況を特定して、次に、新しいDocument Shepherdを任命するために相談するのは、いすとResponsible Areaディレクター次第です。
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は過程を守るドキュメントが適用されない他の例について議論します。
3.1. Document Shepherd Write-Up
3.1. ドキュメント羊飼い記事
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への服従の準備ができていると決めるとき、それはドキュメントのための「ドキュメント羊飼い記事」を完成するDocument Shepherdに関するタスクです。
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つの部品があります。 最初に、Document Shepherdは質問に答えます。(ワーキンググループの過程に関するこのドキュメントに適用されたResponsible Areaディレクター洞察を与えるためには以下の(1.j)への1.a)。 いくつかの場合、これらの質問が余分に見えているかもしれない間それらが書かれていることに注意して、Responsible Areaディレクターが意識しているに違いない(このために、WGアーカイブにおける関連エントリーへのポインタは有用です)情報を引き出してください。 ここの目標はメーリングリストの上、または、IETFミーティングか、それらが見張られたドキュメントのIESG Evaluationの前で意識しているべきである私信で上って来たどんな問題に関してもResponsible Areaディレクターに知らせることです。 アンケートで参照されたどんな重要な問題もたぶんResponsible Areaディレクターとの追跡している議論につながるでしょう。
The second part of the task is to prepare the "Document Announcement Write-Up" that is input both to the ballot for the IESG telechat and to the eventual IETF-wide announcement message. Item number (1.k) describes the elements of the Document Announcement Write-Up.
タスクの第二部はIESG telechatへの投票と、そして、最後のIETF全体の発表メッセージに入力される「ドキュメント発表記事」を準備することです。 商品番号(1.k)はDocument Announcement Write上がることの要素について説明します。
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.
Document Announcement Write-上に関するいくつかの例がAppendix Aに含まれています、そして、IETF発表しているメーリングリストアーカイブには「プロトコル動作」や「ドキュメント動作」などの件名があるずっと多くの例があります。
Levkowetz, et al. Informational [Page 5] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[5ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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.
Document Shepherd Write上がる初期のテンプレートは以下に含まれていますが、変化は時間がたつにつれて、予想されます。 このテンプレートの最新版はIETFウェブサイトのIESG部から利用可能です。
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
(このドキュメントのためのDocument Shepherdである1.a)? Document Shepherdは個人的にドキュメントのこのバージョンを見直しました、そして、特に、その人は公表において、このバージョンが推進の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メンバーからの適切なレビューがありましたか? Document Shepherdには、何か実行されたレビューの深さか幅に関する心配がありますか?
(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) Document Shepherdには、ドキュメントが、より多くのレビューを必要とするという関心が特定の、または、より広い見解、例えば、セキュリティ、操作上の複雑さ、国際化、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) Document Shepherdには、何かResponsible Areaディレクター、そして/または、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) だれか、上告を脅かしますか、別の方法で極端な不満を示しましたか? そうだとすれば、別々のメールメッセージにおける闘争の領域をResponsible Areaディレクターへまとめてください。 (このアンケートがID Trackerに入れられるので、それは別々のメールにあるべきです。)
(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
(1.g) Document Shepherdは、ドキュメントがすべてのID夜を満たすことを個人的に確かめましたか? ( http://www.ietf.org/ID-Checklist.html と http://tools.ietf.org/tools/idnits/ を見てください。) 決まり文句のチェックは十分ではありません。 このチェックは、徹底的である必要があります。 ドキュメントを持っています。
Levkowetz, et al. Informational [Page 6] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[6ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.
それがMIB医師などのようなメディアタイプ、およびURIタイプレビューに必要とするすべての正式な実績評価基準を満たしましたか? ドキュメントが最初のページの上部で既に意図している状態を示さないなら、ここで意図している状態を示してください。
(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].
(1.h) ドキュメントは参照を標準で有益に分けましたか? 前進の準備ができていないか、またはそうでなければ、不明瞭な状態にあるドキュメントの引用規格がありますか? そのような引用規格が存在しているなら、彼らの完成のための戦略は何ですか? [RFC3967]で説明されるように下方向参照である引用規格がありますか? そうだとすれば、これらの下方向参照を記載して、それら[RFC3967]のためにLast Call手順でAreaディレクターを支持してください。
(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) Document ShepherdはドキュメントのIANA Considerations部が存在していて、ドキュメントのボディーと一致していることを確かめましたか? ドキュメントがプロトコル拡大を指定するなら、予約は適切なIANA登録で要求されますか? IANA登録は明確に特定されますか? ドキュメントが新しい登録を作成するなら、それは登録の提案された初期のコンテンツと将来の登録証明書のための配分手順を定義しますか? それは妥当な名前を新しい登録に示しますか? [RFC2434]を見てください。 ドキュメントがExpert Reviewの過程について説明するなら、Document Shepherdは、IESGがIESG Evaluationの間、必要なExpertを任命できるように、Responsible Areaディレクターと打ち合わせましたか?
(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) Document ShepherdはBNF規則、MIB定義などがXMLコードなどのように自動化された市松模様で正しく有効にする形式言語で書かれているドキュメントのそのセクションについて確かめましたか?
(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承認の発表は上にDocument Announcement Writeを含んでいます。 上にそのようなDocument Announcement Writeを提供してください。 承認されたドキュメントのための「動作」発表で最近の例を見つけることができます。 承認の発表は以下のセクションを含みます:
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.
ドキュメントの要約、そして/または、導入で頻繁に技術的なSummary Relevant内容を見つけることができます。 まして、これは要約か序論には欠乏があるという指示であるかもしれません。
Levkowetz, et al. Informational [Page 7] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[7ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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で処理されます。作業部会Summary Was、それは注意する価値がありますか? 例えば、論争が特定のポイントに関するものでしたかそれともコンセンサスがどこで特に荒かったかという決定がありましたか?
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?
そこにQuality Areを記録してください、プロトコルの既存の実現-- 多くの業者が仕様を履行する彼らの計画について簡単に述べましたか? 何か徹底的なレビューをしたとして特記に値する評論家、例えばドキュメントには重要な問題が全くなかったという重要な変化か結論をもたらしたものがありますか? MIB医師(メディアType)か他のExpert Reviewがあったなら、コース(簡潔である)は何でしたか? メディアType Reviewの場合では、要求はどんな日付に掲示されましたか?
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>.'
人員WhoはこのドキュメントのためのDocument Shepherdですか? Responsible Areaディレクターはだれですか? ドキュメントがIANA専門家を必要とするなら、差し込み'登録へのIANA Expert(s)は<TO BE ADDED BY THE AD本書では>です'。
The Document Shepherd MUST send the Document Shepherd Write-Up to the Responsible Area Director and iesg-secretary@ietf.org together with the request to publish the document. The Document Shepherd SHOULD also send the entire Document Shepherd Write-Up to the working group mailing list. If the Document Shepherd feels that information which may prove to be sensitive, may lead to possible appeals, or is personal needs to be written up, it SHOULD be sent in direct email to the Responsible Area Director, because the Document Shepherd Write-Up is published openly in the ID Tracker. Question (1.f) of the Write-Up covers any material of this nature and specifies this more confidential handling.
Document Shepherdが発信しなければならない、Document Shepherd Write-Up、ドキュメントを発表するという要求に伴うResponsible Areaディレクターと iesg-secretary@ietf.org 。 また、Document Shepherd SHOULDが全体を送る、Document Shepherd Write-Up、ワーキンググループメーリングリスト。 Document Shepherdが、敏感であると判明するかもしれないか、可能な上告に通じるかもしれないか、または書かれるべき個人的ニーズが上昇して、それがSHOULDであるということである情報がダイレクトに送られると感じるなら、Responsible Areaディレクターにメールしてください、Document Shepherd Write-上がID Trackerでオープンに発行されるので。 Write上がることの質問(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).
Document Shepherd Write上がるのは「コメント」としてID Tracker[IDTRACKER]に入れられます。 Document Shepherdの名前とEメールアドレスはID Trackerに入力されます、現在、「短信」として(これは将来、変化するかもしれません)。 また、「変化が気付く状態かバージョン」分野にDocument ShepherdのEメールアドレスを加えなければなりません(通常、すべてのワーキンググループいす、作者、および秘書のEメールアドレスは加えられるでしょう)。
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
Document Shepherdの名前とメールをID Trackerに入力するのは、その人がエディタと、いすと、IESGと、IESG事務局と、IANAと、RFC Editorの間のメール交換のときにレビューと承認審査方式の間コピーされるのを保証するREQUIREDです。 まだ、これらに、必要なステップがパーティーへ行くマニュアルがあります。
Levkowetz, et al. Informational [Page 8] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[8ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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.
彼らがDocument Shepherdを含んでいますが、将来自動化されたツールが、Document Shepherds(そして、他のもの)が必要なコミュニケーションを受け取るのを確実にすることが望まれているのを確実にしてください。
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]、領域の管理職、および他のレビューチームに、Document Shepherdのための問い合わせ先も重要であるので、彼らは、レビューを記述するのをだれに知ることができるか、Responsible Areaディレクターに加えて。
3.2. Document Shepherding during AD Evaluation
3.2. ADの間に評価を守るドキュメント
The steps for document shepherding during AD Evaluation are as follows:
ADの間にEvaluationを見張るドキュメントのためのステップは以下の通りです:
(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.
(Responsible Areaディレクターの2.a)はドキュメントを読んで、評価して、批評します、過程を守りながらドキュメントを使用しないとき、そうであるように。 Responsible Areaディレクターが、ドキュメントがIESG Evaluationの準備ができていると決心しているなら、その人は、Document Shepherdと過程を守るドキュメントへのこれがセクション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) Responsible AreaディレクターがIESG Evaluationが始まることができる前に記述しなければならないドキュメントと問題を同一視したなら、その人は完全評価をDocument Shepherdに送って、また、SHOULDはID Trackerにレビューを入れます。
(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) Document ShepherdはAD Evaluationコメントを読みます、すべてのコメントが理解されているのを非常に確信している型、エディタとワーキンググループがそれらの上で追求されるのが、可能であるように。 あれば、何らかの不確実性が何に関して要求されるか、そして、これはSHOULDです。Responsible Areaディレクターと共に決議されてください。
(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) Document Shepherdはエディタと、そして、ワーキンググループメーリングリストにAD Evaluationコメントを送ります、コメントの永久的な記録を持つために。 Document Shepherdがエディタから必要な変化が終了して、改訂されたドキュメントを予想できる時に関する見積りに請求するのは、RECOMMENDEDです。 また、問題追跡SHOULDを使用するワーキンググループが問題(そして、結局彼らの解決)を彼らの問題追跡者に記録します。
(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.
AD Evaluationコメントを記述する改訂されたドキュメントの生産の間の(2.e)、エディタがリストに各コメントがどのように記述されたか、そして、校訂本が何であるかを示させ続けるのは、RECOMMENDEDです。 改訂されたドキュメントと共にこのリストをResponsible Areaディレクターに転送するのは、RECOMMENDEDです。
Levkowetz, et al. Informational [Page 9] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[9ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
(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) エディタかワーキンググループが以前に問題をResponsible Areaディレクターによって上げられるコメントに意見を異にするか、考えて、または捨てた場合、改訂されたドキュメントを提出できる前にDocument ShepherdはResponsible Areaディレクターの問題を解決しなければなりません。
(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.
Document Shepherdがエディタと共に繰り返す(2.g)、(そして、ワーキンググループ、必要なら)、すべてまで、未解決の問題は解決されて、改訂されたドキュメントは利用可能です。 ここに、Document ShepherdはResponsible Areaディレクターに通知して、改訂されたドキュメント、問題の概要、および結果として起こるテキスト変化をその人に提供します。
(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)Responsible Areaディレクターは、その人がAD Evaluationの間に見つけた問題がドキュメントの改訂版でステップのこのセクションで説明された過程を始めることによって解決されていることを確かめます。(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 Last Callを受けて、ADが、重要な問題がLast Callの間提起されたと結論を下すなら、(2.h)を通したステップ(2.b)は、Last Call問題を記述しながら適用される必要があります。 これは、Responsible AreaディレクターがIESGだけに提起されたそれらのLast Call問題をDocument Shepherdに提示するのを必要とします。
3.3. Document Shepherding during IESG Evaluation
3.3. 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 Evaluationの間、ADsはドキュメントに関する所見の2種類を前方に連れて来ることができます: DISCUSSの品目とCOMMENTの品目 それが決議されるまで、DISCUSSはドキュメントの承認審査方式を妨げます。 COMMENTはそうしません。 このセクションはDocument Shepherdが項目がIESG Evaluationの間に見張られたドキュメントに対して早めたどんなDISCUSSとCOMMENTも決議するために採る方法を詳しく述べます。
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.
DISCUSSとCOMMENTの品目が彼らの意図を不明瞭にする方法で時折書かれていることに注意してください。 これらの場合では、Document Shepherd SHOULDは彼らの意図をはっきりさせるために商品を持って来たADsと共に議論を始めます、Responsible Areaディレクターに知らせ続けて。 これが意図をはっきりさせないなら、Responsible Areaディレクターは、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
(IESG電話会議までの3.a)の通じる、Document ShepherdはID Trackerに入れられた1ADsとまた、メールされたコピーのDISCUSSとCOMMENTの品目を代表して管理職の評論家からドキュメントに関するメールを見るかもしれません。 Document Shepherd SHOULDはすぐに彼らを上げたADsがあるDISCUSSとCOMMENTの品目を決議するのに働き始めます、コピーされたResponsible Areaディレクターをオンに保って
Levkowetz, et al. Informational [Page 10] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[10ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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.
その人が電話会議の間、活動を支持できるためのメール交換。 管理職レビューに対処するとき、Document Shepherdはこれらの管理職がこれらのADsが決議する必要があるレビューコメントを考えるのを保証すると報告するADsにかかわらなければなりません。
(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".
例えば、ドキュメント変化がすぐに状態を「IESG評価」よりDocument Shepherd動作を必要とする州の1つに述べるとき電話会議に続く(3.b)、「IESG評価:」 または、「改訂されたIDが必要であった」、「IESG評価:」 「AD Followup」、Document Shepherdはメールを受け取るでしょう。 または、「AD追跡」の状態が解決が継続的な議論で可能であるかもしれないというResponsible Areaディレクターの望みを通常意味する、(より通常) 「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.)
DISCUSSの品目がIESG電話会議の後に登録されるとき、非常に例外的なケースがあるかもしれないことに注意してください。 これらのケース、DISCUSS MUSTを上げたADのときに、それに関してDocument Shepherdに通知してください。 (この目的とそれらが部分的に決議された後にDISCUSSとCOMMENTの品目がアップデートされるケースもID Trackerの通知施設は非常に都合がよいです。)
(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) そして、Document Shepherdは、項目がドキュメントに対して上げた残っているDISCUSSとCOMMENTを集めるためにID Trackerについて質問します。 Document Shepherdは彼らを置いたADsと共にこれらの項目を分析して、接触を初期化します。 アクティブなDISCUSSかCOMMENTの品目に関連するすべての通信にResponsible Areaディレクターをコピーしなければなりません。これは、解決に向かったクリティカルパスにResponsible Areaディレクターを置きませんが、議論の状態に関してその人に知らせ続けるべきです。
+-------+ +-------+ +-------+
| (3.b) | -----------> | (3.c) | ------------> | (3.d) |
+-------+ Comments +-------+ Comments +-------+
collected /|\ | understood
| |
| | Comments not fully understood
| | (Further AD/Document Shepherd
| | discussion required)
+---+
+-------+ +-------+ +-------+ | (3.b) | ----------->| (3.c) | ------------>| (3.d) | +-------+ コメント+-------+ コメント+-------+ 集まっている/|\ | 理解されています。| | | | 完全に理解されていたというわけではないコメント| | (Shepherd| | 議論が必要としたさらなる西暦/ドキュメント) +---+
(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) Document Shepherdは次に、DISCUSSとCOMMENTの品目の解決を調整して、コメントの一貫した解釈を組み込みます。 このステップはセクション3.2で説明された過程の多くと同様です。
Levkowetz, et al. Informational [Page 11] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[11ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
+-------+ +-------+
| (3.c) | ---------------> | (3.d) |
+-------+ Consistent +-------+
/|\ interpretation |
| | Further AD/Document Shepherd
| | discussion required
+--------------------------+
+-------+ +-------+ | (3.c) | --------------->| (3.d) | +-------+ 一貫した+-------+ /|\解釈| | | さらなる西暦/ドキュメント羊飼い| | 議論は+を必要としました。--------------------------+
(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) 次に、Document ShepherdはDISCUSSとCOMMENTの品目をドキュメントエディタとワーキンググループに伝えます、ドキュメントへのIESG処理の間に蓄積しているどんな変化の彼らも警告して、「RFCエディタへの注意」などのように。 どれか変化が実質的になるなら、Responsible Areaディレクターとの他のステージのような相談では、Document Shepherdはワーキンググループコンセンサスか時々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) エディタがDISCUSSとCOMMENTの品目を決議した後に、Document Shepherdは改訂されたドキュメントか、1セットの「RFCエディタへの注意」か、両方になるドキュメントの結果として起こる新しいバージョンを見直します、すべてがDISCUSSを上げて、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.
また、Document ShepherdがDISCUSSとCOMMENTの品目に解決を勧めるかもしれないことに注意するか、問題追跡者にそれらを入れるか、または他のステップを実行して、評価コメントの解決を能率化してください。 議論がかかわった皆にとってよく見られる間、タイムリーな方法でコメントを決議するのは非常に重要です。
(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) Document Shepherdが改訂されたドキュメントが評価コメントを記述するのに満足しているとき、その人はDISCUSSとCOMMENTの品目を上げたResponsible AreaディレクターとADsに解決を伝えます。
(3.h) Each AD who had raised a DISCUSS checks whether the
communicated resolution addresses his or her items. If it
does, the AD will clear the DISCUSS. If it does not, the AD
notifies the Document Shepherd and adds information to the ID
Tracker explaining why the DISCUSS was not resolved. The
Document Shepherd informs the working group accordingly.
(COMMENT items need not be checked and cleared, because they
do not block the document, but ADs are encouraged to do so.)
DISCUSSを上げた各ADは、コミュニケートしている決議がその人の項目を記述するかどうかチェックしました。(3.h) そうすると、ADはDISCUSSをきれいにするでしょう。 そうしないなら、ADはDISCUSSがなぜ決議されなかったかを説明するID TrackerにDocument Shepherdに通知して、情報を加えます。 Document Shepherdはそれに従って、ワーキンググループに知らせます。 (ドキュメントを妨げないので、COMMENTの品目は、チェックされて、クリアされる必要はありませんが、ADsがそうするよう奨励されます。)
If a DISCUSS was not resolved to the satisfaction of the AD
that has raised it or the Responsible Area Director, two
possibilities exist:
DISCUSSがそれを上げたADかResponsible Areaディレクターの満足に決議されなかったなら、2つの可能性が存在しています:
Levkowetz, et al. Informational [Page 12] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[12ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
(a) The process returns to step (3.d), or
または(a) 過程が戻って、(3.d)を踏む。
(b) If no progress can be made on the resolution of the
DISCUSS with the AD who has raised it, despite repeated
clarifications and discussions, the Responsible Area
Director should take over continued shepherding of the
document. Such a situation may be indicative of larger
issues that the PROTO process was not designed to handle.
(b)ADと繰り返された明確化と議論にもかかわらず、それを上げたDISCUSSの解決のときに進歩を全く見られることができないなら、ドキュメントが見張られながら、Responsible Areaディレクターは続けられていた状態で引き継ぐべきです。 そのような状況はプロトの過程が扱うように設計されなかったより大きい問題を暗示しているかもしれません。
Once the process above has cleared all DISCUSS items, document
shepherding continues with step (3.i).
ドキュメントの見張るのは、一度、上の過程がすべてのDISCUSSの品目をクリアしたことがありステップ(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) Responsible AreaディレクターはドキュメントをID Trackerの「承認されました--送られる発表」という状態に動かします。 その人が、改訂されたドキュメントへの変化が重要であると考えるなら、新しいWG Last Call、またはことによると新しいIETF Last Callがあるかもしれません。 新しいIETF Last Callがあれば、ドキュメントは新しい完全なIESG Evaluationの過程に直面しています。
4. Shepherding the Document's IANA Actions
4. ドキュメントのIANA動作を見張ります。
IETF working group documents often include considerations requiring actions by the IANA, such as creating a new registry or adding information to an existing registry, perhaps after consulting an IESG-appointed Expert. Sometimes the Document Shepherd must keep track of certain IANA actions to be completed by the IESG, such as ratifying the appointment of a designated Expert called for in the IANA Considerations. IANA-related processing may also include a specified type of Expert review, such as review of proposed MIME media types on the designated ietf-types mailing list.
IETFワーキンググループドキュメントはしばしばIANAによる動作を必要とする問題を含んでいます、新しい登録を作成するか、または既存の登録に情報を加えるのなどように、恐らくIESGが指定しているExpertに相談した後に。 時々、Document Shepherdは、IANA Considerationsの求められた指定されたExpertのアポイントメントを批准などなどのIESGによって完成するためにあるIANA動作の動向をおさえなければなりません。 また、IANA関連の処理は指定されたタイプの指定されたietf-タイプメーリングリストにおける提案されたMIMEメディアタイプのレビューなどのExpertレビューを含むかもしれません。
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 Last Callに対応したドキュメントのIESG Evaluationレビュー、IANAがドキュメントのためにウェブベースの登録で動作を実行するいつもでない、しかし、通常ドキュメントの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].
この公表時点で、RFC2434が改正[RFC2434bis]であって、アップデートには、あって、Document Shepherdには価値があるでしょう。 Document Shepherdがその人のドキュメントのために最新の、そして、最も適切なIANA情報であることと指導を決定しなければならないことに(他のものとの個々のレビューと相談で)注意してください、総合的な指導、またはその人の領域、または他の領域の外部のドキュメントであることにかかわらず。 外部のドキュメントに関する例は[RFC4020]です。
Levkowetz, et al. Informational [Page 13] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[13ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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 MUSTからの見張ることの過程、リクエスタのいかなる段階の間も、来るときはいつも、Document ShepherdとResponsible Areaディレクターがともに要求を受け取るのを確実にしてください。 Document Shepherdは早急に応じるのに責任があります。 その人はワーキンググループと共にどんな可能な関心も導入する要求について議論するべきです。 Document ShepherdとResponsible Areaディレクターは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.
一般に、Document Shepherdはそれを確実にします。IANAの過程が完成する、IANAマトリクス( http://www.iana.org/numbers.html )が登録が正しく、完全であって、一貫しているのをチェックして、すべてが順調であるというわけではないときに、障害調査します。 IANA処理の終わりに、Document ShepherdはRFC Editorが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動作を見張るタスクは、しばしば見落とされますが、調整して、管理するためにDocument Shepherdが管理した他のすべてのドキュメントレビューと同じくらい重要です。 それらのように、Document Shepherdはドキュメントの品質とタイムリーにIANA要求を有効で敏感な見張ることで大いに貢献します。
5. Document Shepherding after IESG Approval
5. IESGの後に承認を見張るドキュメント
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 Evaluationと解決の後に、IESGはドキュメントを承認します、そして、Responsible AreaディレクターはDocument Announcement Write上がるのとそれのためのどんな最終的な変化も発行されるように頼むのにID Trackerを使用します。 Document Shepherdには、Responsible Areaディレクターのためのいくつかの編集があるかもしれません、小さい方の「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 Editor、および現在のDocument Shepherd(Announcement Write上がるところでは、特定される)に続けています。 RFC Editorは現在、作者、Document Shepherd、およびResponsible Areaディレクターに多くのタイプの要求を出します。 Document Shepherd SHOULDは公表にRFC Editorに応じる際に導いて、ポスト認可期間の間、ドキュメントを守ります。
The RFC Editor request types include: editorial queries about dangling or missing informative and normative citations (good shepherding should try to catch these earlier, but they happen); requests for the document source (e.g., XML or nroff); occasional
RFC Editorは、タイプはである:要求します。 ぶらぶらするかなくなった有益で標準の引用(十分な見張るのは、これらが、より初期であることを捕らえようとするべきですが、それらは起こる)に関する編集の質問。 ドキュメントソース(例えば、XMLかnroff)を求める要求。 時々
Levkowetz, et al. Informational [Page 14] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[14ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
technical comments; and copy-edits for review and close scrutiny by the authors (AUTH48). For the latter, the Document Shepherd SHOULD lead in checking that copy-edits have in no case affected a consensus wording of the working group that prepared the document, and SHOULD bring speed to this checking by multiple coauthors. The Document Shepherd also consults with the Responsible Area Director on reviewing proposed post-approval changes to the document by any author. These may require Area Director approval, and they often need to be presented to the working group for consent if not a full consensus procedure.
技術的なコメント。 そして、作者(AUTH48)によるレビューと厳密な調査のためにコピー編集。 後者のために、コピー編集がドキュメントを準備するワーキンググループのコンセンサス言葉遣いに決して影響しなかったのをチェックする際にDocument Shepherd SHOULDは導きます、そして、SHOULDは複数の共著者によるこの照合に速度をもたらします。 また、Document Shepherdはどんな作者によるドキュメントへの提案されたポスト承認の変化も見直すことに関してResponsible Areaディレクターと相談します。 これらはAreaディレクター許可を必要とするかもしれません、そして、彼らはしばしば同意か完全なコンセンサス手順のためにワーキンググループに提示される必要があります。
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.
ドキュメントの見張ることの他のフェーズのように、Document Shepherdは、ドキュメントの知識がある代表として勤めて、前進とその保全を助けることによって、注意深さとタイムリーさであるのを提供します。
6. When Not to Use the Document Shepherding Process
6. 過程を守って、いつドキュメントを使用しませんか。
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、Document Shepherd SHOULDが見張られたドキュメントのエディタでないと言及するので。 これを避けることができないなら、過程SHOULD NOTを見張りながら別のワーキンググループいすか秘書にDocument Shepherd、ドキュメントを作ることによって、使用されてください。 ドキュメントの見張るのがSHOULD NOTを処理する他のいくつかの場合があります。使用されます。 これらは:
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. Document Shepherdがドキュメントの大きな割合の第一の作者かエディタであるケースはワーキンググループで発生しました。
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. Responsible AreaディレクターがDocument Shepherd(経験、Document Shepherdによって述べられた、強い視点、または他の問題による)におけるコミュニケーション困難を予想するケース。
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.
最終的に、過程を守りながらドキュメントを使用するのが生産的でないかもしれない他の場合が存在することに注意してください。 過程を守りながらドキュメントを使用するかどうかに関する最終的決定はResponsible Areaディレクターに任せます。 過程を守るドキュメントが使用されていないなら、Responsible AreaディレクターはDocument Shepherdとして務めます、Areaでディレクターを導く既存の手順単位で。
Levkowetz, et al. Informational [Page 15] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[15ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
7. Security Considerations
7. セキュリティ問題
This document specifies a change to IETF document-processing procedures. As such, it neither raises nor considers protocol- specific security issues.
このドキュメントはIETF文書処理手順への変化を指定します。 そういうものとして、それは、プロトコルが特定の安全保障問題であると上げでない、また考えません。
8. IANA Considerations
8. IANA問題
This document creates no new requirements on IANA namespaces or other IANA requirements.
このドキュメントはIANA名前空間か他のIANA要件にどんな新しい要件も作成しません。
9. Acknowledgments
9. 承認
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.
このドキュメントはプロトチームの製品です。(それは、ビル・フェナー、バーバラ・フラー、およびマーガレット・ワッサーマンと同様に作者を含んでいます)。 プロトで活発に2006年の始まりまで働いて、ドキュメントの以前のバージョンに働くアーロン・フォーク。
The Document Shepherd Write-Up originated in an idea by John Klensin. Thomas Narten and Margaret Wasserman implemented it for the entire Internet Area, and their template was the basis of the version used today.
Document Shepherd Write上がるのはジョンKlensinで考えで起こりました。 トーマスNartenとマーガレット・ワッサーマンは全体のインターネットAreaのためにそれを実行しました、そして、それらのテンプレートは今日使用されているバージョンの基礎でした。
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.
Appendix A.1に草稿ietf-avt-rtpミディ形式のための上にオリジナルのDocument Announcement Writeを含んでいて、コリン・パーキンスは書きました。 Appendix A.2に草稿ietf-imss-ip過剰繊維チャンネルのための上にオリジナルのDocument Announcement Writeを含んでいて、デヴィッドBlackは書きました。 両方のオリジナルの発表は、それらが書かれたのでDocument Announcement Write上がっているテンプレートへの変化を反映するように変更されました。
Frank Ellermann and Olafur Gudmundsson have suggested improvements to the document during IETF Last Call.
フランクEllermannとOlafurグドムンソンはIETF Last Callの間、ドキュメントへの改良を勧めています。
Levkowetz, et al. Informational [Page 16] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[16ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
10.2. Informative References
10.2. 有益な参照
[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配分」BCP100、2005年2月のRFC4020。
[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問題部に書くためのガイドライン」BCP26、RFC2434(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、「Standards Track Documentsがそうするときのはっきりさせる、Lower LevelのDocumentsへのRefer Normatively、」、BCP97、RFC3967(2004年12月)
[RFC2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", Work in
Progress, March 2007.
[RFC2434bis] 「RFCsにIANA問題部に書くためのガイドライン」というNarten、T.、およびH.Alvestrandは進歩、2007年3月に働いています。
[IDTRACKER] "The IETF Internet-Draft Tracker", Web
Application: https://datatracker.ietf.org/, 2002.
[IDTRACKER] 「IETFインターネットドラフト選手」、ウェブアプリケーション: https://datatracker.ietf.org/ 、2002。
[PROTO] "The IESG PROcess and TOols (PROTO) Team", Web
Page: http://psg.com/~mrw/PROTO-Team, 2004.
「IESGの過程とツール(プロト)は組にする」[プロト]、ウェブページ: 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.
[芸術に情報を得ている] 「一般領域レビューチーム(芸術に情報を得ている)」、ウェブページ: http://www.alvestrand.no/ietf/gen/ レビュー-guidelines.html、2005。
Levkowetz, et al. Informational [Page 17] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[17ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
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.
この付録はDocument Announcement Write上に関する2つの例を含んでいます。 IETF発表しているメーリングリストアーカイブで「プロトコル動作」や「ドキュメント動作」などのSubject線があるずっと多くの例を見つけることができます。
A.1. Example Document Announcement Write-Up for
draft-ietf-avt-rtp-midi-format
A.1。 草稿ietf-avt-rtpミディ形式において、Document Announcement Write上がっている例
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 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.
マグヌスWesterlundとコリン・パーキンスは共同でこのドキュメントを守りました。 アリソン・マンキンはIESGのためのドキュメントを再検討しました、メディアタイプのエディタとの慎重なレビューを含んでいて、問題を全く提起しなかった2006年1月8日に要求されたietf-タイプリストレビューと平行して。
Levkowetz, et al. Informational [Page 18] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[18ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
A.2. Example Document Announcement Write-Up for
draft-ietf-imss-ip-over-fibre-channel
A.2。 草稿ietf-imss-ip過剰繊維チャンネルにおいて、Document Announcement Write上がっている例
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.
このドキュメントはFibre Channelの上でIPv6、IPv4、およびARPパケットのカプセル化を指定します。 また、このドキュメントは、Fibre Channelネットワークの上のIPv4アドレス解決を実行するためにIPv6のリンクローカルのアドレスと国がない自動構成されたIPv6アドレスをFibre Channelネットワークに形成するための方法、およびメカニズムを指定します。 このドキュメント(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のメンバーに加えてTechnical Committee T11(繊維Channel規格組織)のFibre Channel専門家によって再検討されました。 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.
このドキュメントは、Fibre Channel(RFC3831)の上のFibre Channel(RFC2625)とIPv6の上でIPv4の上の2別々のRFCsを取り替えて、統合します。 技術的な内容の大部分はそれらのRFCsから変わりがありません。 作られている技術変化は主として実現経験に基づいています。
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.
プロトコルはIESGのためにデヴィッドL.Black(WGいす)によって見直されました。 バートWijnenはIESGのためのこのドキュメントを再検討しました。 さらに、WG-いす(デヴィッドBlack)でブライアン・ハーバーマンはINT Areaのために要求された通りマーガレット・ワッサーマンを通してレビューしました。
Levkowetz, et al. Informational [Page 19] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[19ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
Authors' Addresses
作者のアドレス
Henrik Levkowetz Torsgatan 71 Stockholm S-113 37 Sweden
Henrik Levkowetz Torsgatan71ストックホルムS-113 37スウェーデン
Phone: +46 708 32 16 08 EMail: henrik@levkowetz.com
以下に電話をしてください。 +46 708 32 16 08はメールされます: henrik@levkowetz.com
David Meyer 1225 Kincaid St Eugene, OR 97403 USA
デヴィッド・マイヤー1225・キンケイドStユージン、または97403米国
Phone: +1 541 346 1747 EMail: dmm@1-4-5.net
以下に電話をしてください。 +1 1747年の541 346メール: dmm@1-4-5.net
Lars Eggert Nokia Research Center P.O. Box 407 Nokia Group 00045 Finland
ラースエッゲルトノキアリサーチセンター私書箱407Nokia Group00045フィンランド
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 ユリ: 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 メールしてください: mankin@psg.com ユリ: http://www.psg.com/~mankin
Levkowetz, et al. Informational [Page 20] RFC 4858 Document Shepherding to Publication May 2007
Levkowetz、他 情報[20ページ]のRFC4858は2007年5月に公表への見張ることを記録します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Levkowetz, et al. Informational [Page 21]
Levkowetz、他 情報[21ページ]
一覧
スポンサーリンク
