[要約] RFC 6385は、General Area Review Team（Gen-ART）の経験に関するドキュメントであり、Gen-ARTの役割と活動について説明しています。このRFCの目的は、Gen-ARTの役割を理解し、その活動を改善するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) M. Barnes
Request for Comments: 6385 Polycom
Category: Informational A. Doria
ISSN: 2070-1721 Research Consultant
H. Alvestrand
Google
B. Carpenter
University of Auckland
October 2011
General Area Review Team (Gen-ART) Experiences
一般エリアレビューチーム（Gen-Art）の経験
Abstract
概要
The General Area Review Team (Gen-ART) has been doing reviews of Internet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF Last Call is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda.
General Area Reviewチーム（Gen-ART）は、2004年以来、インターネットドラフト（I-DS）のレビューを行っています。このドキュメントでは、このプロセスの過去7年間に学んだ経験と教訓について説明しています。レビューチームは、最初にIESGテレシャットのそれぞれの前にI-DSをレビューしました。2005年後半以来、IETFの最後の呼び出しがI-Dに必要でない限り、IETFの最後の呼び出し中にレビューチームメンバーがI-DSをレビューするように割り当てられています。同じレビュー担当者は、I-DがIESG Telechatのアジェンダに配置されたときに更新を確認します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6385.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6385で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Who Are the Gen-ART Members? ....................................3
3. Goals of Gen-ART ................................................3
4. Gen-ART Reviews .................................................4
4.1. IETF Last Call Review Process ..............................4
4.2. IESG Telechat Review Process ...............................5
4.3. Form of Review .............................................5
4.4. Gen-ART Process Overview ...................................8
5. Secretarial Process ............................................10
5.1. Maintaining Review Spreadsheet ............................10
5.2. Last Call Assignment Procedure ............................12
5.3. Telechat Assignment Procedure .............................13
5.4. Capturing Reviews .........................................14
6. Results ........................................................14
7. Impressions ....................................................15
7.1. Reviewers' Impressions ....................................15
7.2. General Area Directors' Impressions .......................17
7.3. Gen-ART Secretaries' Impressions ..........................18
8. Needed Improvements ............................................18
9. Applicability ..................................................20
10. Security Considerations .......................................20
11. Acknowledgments ...............................................20
12. Informative References ........................................21
The General Area Review Team (Gen-ART) was created personally by the General Area Director in 2004. This document discusses the experiences and the lessons learned as the process has evolved over the past 7 years. The process described in this document reflects that which was in place at the time this document was published.
一般エリアレビューチーム（Gen-ART）は、2004年に一般的なエリアディレクターによって個人的に作成されました。このドキュメントでは、過去7年間にプロセスが進化したときに学んだ経験と教訓について説明しています。このドキュメントに記載されているプロセスは、このドキュメントが公開された時点で実施されていたプロセスを反映しています。
This process is likely to continue to change over time. The review team has been retained by subsequent General Area Directors. It has no official role in the IETF standards process, except as a set of individuals entitled, like everyone, to comment on Internet-Drafts (I-Ds). Its volunteers, including a secretary and the team of reviewers, serve at the invitation of the General AD. Both the reviews and the reviewer names are public.
このプロセスは、時間の経過とともに変化し続ける可能性があります。レビューチームは、その後の一般的なエリアディレクターによって保持されています。IETF標準プロセスでは、インターネットドラフト（I-DS）についてコメントする資格のある個人のセットを除き、IETF標準プロセスには公式の役割はありません。秘書やレビュアーのチームを含むボランティアは、一般的な広告の招待で奉仕しています。レビューとレビュアー名の両方が公開されています。
The reviewers are typically individuals that have a fair amount of experience within various IETF Working Groups (WGs), have authored WG I-Ds and RFCs, and are often considered to be subject matter experts (SMEs) in their particular areas of work. The current review team is comprised of such technical experts, including several WG chairs as well as past and current Internet Architecture Board (IAB) members. Several past and current ADs have served as reviewers. Two past General ADs have also served as reviewers, with one currently serving.
レビュアーは通常、さまざまなIETFワーキンググループ（WGS）でかなりの経験を持ち、WG I-DSおよびRFCを執筆しており、多くの場合、特定の作業分野で主題の専門家（SME）と見なされます。現在のレビューチームは、いくつかのWGチェアや、過去および現在のインターネットアーキテクチャボード（IAB）メンバーなど、このような技術専門家で構成されています。いくつかの過去および現在の広告がレビュアーを務めています。過去の2つの一般的な広告もレビュアーを務め、1つは現在サービスを提供しています。
Members of the review team sometimes excuse themselves from the team for various reasons, typically due to "day job" demands. However, they often rejoin (for periods of time) as their schedules allow. Also, some reviewers remain on the team, while their review workload is decreased by assigning them just one I-D (at Last Call time) to review each month. Section 11 provides a list of currently active reviewers, along with those who have served on the review team in the past.
レビューチームのメンバーは、通常は「日中の仕事」の要求が原因で、さまざまな理由でチームから自分自身を言い訳することがあります。ただし、スケジュールが許可するように（しばらくの間）再参加することがよくあります。また、一部のレビュアーはチームに残りますが、レビューワークロードは、毎月レビューするために1つのI-D（最後のコールタイム）のみを割り当てることで減少します。セクション11では、過去にレビューチームに参加した人とともに、現在アクティブなレビュアーのリストを提供します。
The original and continuing goal of the Gen-ART was, and is, to offload from the General AD some of the burden of IESG reviews. The load for the bi-weekly IESG reviews is often quite large; occasionally, there are more than 20 I-Ds scheduled for discussion in a single telechat. Thus, ADs also have less than a week's notice for many of the I-Ds on the telechat agenda.
Gen-Artの元の継続的な目標は、IESGレビューの負担の一部を一般的な広告からオフロードすることでした。隔週のIESGレビューの負荷は非常に大きいことがよくあります。時折、単一のテレシャットでディスカッションを予定している20以上のI-Dがあります。したがって、広告には、TelechatアジェンダのI-DSの多くに対して1週間未満の通知もあります。
Gen-ART was based on a model that had proved productive in the Operations (OPS) Directorate: quick review close to telechat time, to advise the AD on issues that remain serious. By having a trusted group of reviewers read and evaluate the I-Ds, the General AD would be able to concentrate on those I-Ds where there was a concern expressed by the reviewer. The reviewers are expected to provide feedback based on a whole set of criteria, including the criteria
Gen-Artは、オペレーション（OPS）局の生産性が証明されたモデルに基づいていました。これは、テレシャットの時間に近いクイックレビューで、深刻な問題について広告に助言することです。信頼できるレビュアーグループにI-DSを読んで評価することにより、一般的な広告は、レビュアーが表明した懸念があるI-DSに集中することができます。レビュアーは、基準を含む一連の基準に基づいてフィードバックを提供することが期待されています
summarized in Section 4.3. The overall objective is to ensure that the I-Ds are well structured; can be easily understood, at least at a high level; and provide a reasonable basis for implementation (for I-Ds intended for the Standards Track).
セクション4.3にまとめられています。全体的な目的は、I-DSが十分に構造化されていることを確認することです。少なくとも高レベルでは、簡単に理解できます。実装の合理的な根拠を提供します（標準トラック向けのI-DSの場合）。
While other area (and WG) directorates/review teams existed prior to Gen-ART and more have been established since Gen-ART, the roles of each are fairly distinct. Thus, there is little overlap between the goals and review criteria for the various review teams. It is also very valuable for these other review teams to operate independently. For example, when both Gen-ART reviews and Security Directorate (SecDir) reviews raise the same sorts of concerns, it's a clear red flag that the I-D needs more work before progressing. In addition, due to the typical thoroughness (and objectiveness) of the various review teams' reviews, the sponsoring AD and document shepherd are often able to work with the editors/WG (and vice versa, depending upon area and WG structure) to improve the overall quality of the final I-D. It should also be noted that some ADs take the Gen-ART reviews into consideration when preparing their own evaluations.
他のエリア（およびWG）局長/レビューチームはGen-Artよりも前に存在していましたが、Gen-Art以来さらに確立されていますが、それぞれの役割はかなり明確です。したがって、さまざまなレビューチームの目標とレビュー基準の間にはほとんど重複していません。また、これらの他のレビューチームが独立して運営することは非常に価値があります。たとえば、Gen-ARTレビューとセキュリティ局（SECDIR）レビューの両方が同じ種類の懸念を提起する場合、I-Dが進行する前にさらに作業を必要とすることは明確な危険です。さらに、さまざまなレビューチームのレビューの典型的な徹底性（および客観性）により、スポンサーADとドキュメントシェパードは、編集者/WG（およびその逆、エリアとWG構造に応じて、その逆）と連携することができることがよくあります。最終的なI-Dの全体的な品質。また、一部の広告では、独自の評価を準備する際にGen-ARTレビューを考慮に入れることに注意する必要があります。
Statistics from the Gen-ART reviews over the past 6+ years show a trend of increased quality and readiness for progression of I-Ds by the time they are placed on the telechat agenda. Additional statistics are discussed in Section 6.
過去6年間のGen-ARTレビューからの統計は、Telechatのアジェンダに掲載されるまでにI-DSの進行の質と準備が増加する傾向を示しています。追加の統計については、セクション6で説明します。
While the original process was meant only for reviews just before the IESG telechat, the decision was made to include IETF Last Call (LC) reviews in early 2005. Over time the latter has proven to be quite effective. Assigning the I-Ds at IETF LC time typically gives a reviewer more time to review an I-D. And, in some cases, the IETF LC version is the one to appear on the telechat. Thus, by the time I-Ds are added to the telechat agenda, a majority (typically at least 70%) have already been reviewed. For those I-Ds that have been up-versioned, the amount of time dedicated to re-review depends upon the review summary for the IETF LC review.
元のプロセスは、IESGテレシャットの直前のレビューのみを対象としていましたが、2005年初頭にIETF Last Call（LC）レビューを含めることが決定されました。IETF LC時間でI-DSを割り当てると、通常、レビュアーにI-Dを確認する時間が増えます。また、場合によっては、IETF LCバージョンがTelechatに表示されるバージョンです。したがって、I-DSがTelechatのアジェンダに追加されるまでに、過半数（通常は少なくとも70％）がすでにレビューされています。バージョンされているI-DSの場合、Reviewに専念する時間は、IETF LCレビューのレビュー概要に依存します。
The assignments at IETF LC time evolved to minimize the gap between LC announcements and assignment time, with the secretary doing LC assignments every Thursday night. This typically allows the reviewer at least one week and sometimes two to three weeks to complete the review. The reviews are obviously most helpful when done on or before the end of the IETF LC.
IETF LC Timeでの割り当ては、LCの発表と割り当て時間のギャップを最小限に抑えるために進化しました。これにより、通常、レビュー担当者が少なくとも1週間、時には2〜3週間でレビューを完了することができます。レビューは、IETF LCの終了時以前に行われたときに明らかに最も役立ちます。
The Last Call assignments are done on a fairly strict round-robin basis to ensure a fair workload amongst all the reviewers. Reviewers that are unavailable (vacations, etc.) during the review period timeframe obviously are excluded from that round of assignments, but remain in the same queue position for the next round. The order is occasionally modified to avoid assigning an editor/author or WG chair their own I-Ds. A reviewer may also NACK an assignment if they feel they may have some bias (although corporate affiliations are not considered to be sources of bias) or they don't feel they can review the I-D in a timely manner.
最後のコール割り当ては、すべてのレビュアーの間で公正なワークロードを確保するために、かなり厳格なラウンドロビンベースで行われます。レビュー期間中に利用できないレビュアー（休暇など）は、明らかにその課題から除外されますが、次のラウンドでは同じキューポジションに留まります。編集者/著者の割り当てやWGチェアの割り当てを避けるために、注文は時々変更されます。また、レビュアーは、バイアスがあると感じた場合（企業の所属はバイアスの原因とは見なされない）、またはタイムリーにI-Dをレビューできるとは思わない場合、割り当てをnackすることもあります。
The assignment process is completely manual, although a spreadsheet tremendously facilitates the process. The details are described in Section 5. Ideally, this process could be automated. However, manual intervention would still be required to maintain the appropriate available reviewer list (unless reviewers took on the task of maintaining their data in some sort of database). Further details on the tools necessary to automate the entire process are provided in Section 8.
割り当てプロセスは完全にマニュアルですが、スプレッドシートはプロセスを非常に促進します。詳細については、セクション5で説明します。理想的には、このプロセスは自動化できます。ただし、適切な利用可能なレビュアーリストを維持するには、手動介入が引き続き必要です（レビュアーが何らかのデータベースでデータを維持するタスクを引き受けない限り）。プロセス全体を自動化するために必要なツールの詳細については、セクション8に記載されています。
The process for reviewing I-Ds when they appear on the IESG agenda is as follows:
IESGアジェンダに表示されたときにi-DSをレビューするプロセスは次のとおりです。
o The "nearly final" IESG meeting agenda generally appears on Thursday night, less than one week before the IESG telechat. The Gen-ART secretary uses this as the input for the assignment process.
o 「ほぼ最終」のIESG会議の議題は、一般に、IESGテレシャットの1週間以内に木曜日の夜に掲載されます。Gen-Art秘書は、これを割り当てプロセスの入力として使用します。
o For I-Ds reviewed at IETF Last Call, a new review is only asked for if the I-D is revised. In this case the reviewer, typically the person who did the Last Call review, only needs to check that any open issues were resolved. Often the draft will not have changed between IETF LC and the IESG telechat review. Section 4.4 provides the step-by-step telechat review assignment process, with specific details on the maintenance of the review assignment data, which is in turn maintained in review spreadsheets (Section 5).
o IETF Last CallでレビューされたI-DSの場合、新しいレビューには、I-Dが改訂されるかどうかのみを求められます。この場合、レビュアー、通常は最後のコールレビューを行った人は、未解決の問題が解決されたことを確認する必要があります。多くの場合、IETF LCとIESG Telechatレビューの間でドラフトは変更されません。セクション4.4は、レビュー割り当てデータのメンテナンスに関する具体的な詳細を備えた段階的なテレシャットレビューの割り当てプロセスを提供します。これは、レビュースプレッドシート（セクション5）で維持されます。
Rather than invent new guidelines, the Gen-ART requirements for the form of a review stole liberally from "Careful Additional Review of Documents (CARD) by Senior IETF Reviewers (SIRS)" [SIRS], making adaptations for the special "late, quick review" case and the nature of the General Area's concerns.
新しいガイドラインを発明するのではなく、レビューの形式のGen-ART要件は、「シニアIETFレビュアー（SIRS）によるドキュメントの慎重な追加レビュー（カード）」[SIRS]から自由に盗まれ、特別な後期、クイックの適応を行っています。「ケースと一般的なエリアの懸念の性質を確認します。
Each review must start with a summary statement chosen from or adapted from the following list:
各レビューは、次のリストから選択または採用された要約ステートメントから開始する必要があります。
o This draft is ready for publication as a [type] RFC, where [type] is Informational, Experimental, etc. (In some cases, the review might recommend publication as a different [type] than requested by the author.)
o このドラフトは、[タイプ] RFCとして公開される準備ができています。[タイプ]は情報、実験などです（場合によっては、レビューでは、著者が要求したものとは異なる[タイプ]として公開されることを推奨する場合があります。）
o This draft is basically ready for publication, but has nits that should be fixed before publication.
o このドラフトは基本的に公開の準備ができていますが、公開前に修正する必要があるnitがあります。
o This draft is on the right track but has open issues, described in the review.
o このドラフトは正しい軌道に乗っていますが、レビューで説明されているオープンな問題があります。
o This draft has serious issues, described in the review, and needs to be rethought.
o このドラフトには深刻な問題があり、レビューに記載されており、再考する必要があります。
o This draft has very fundamental issues, described in the review, and further work is not recommended.
o このドラフトには、レビューで説明されている非常に基本的な問題があり、さらなる作業は推奨されません。
o Unfortunately, I don't have the expertise to review this draft.
o 残念ながら、私はこのドラフトをレビューする専門知識を持っていません。
The length of a review can vary greatly according to circumstances, and it is considered acceptable for purely editorial comments to be sent privately if it's obvious that the I-D needs substantial revision. All substantive comments, however, must be included in the public review. Wherever possible, comments should be written as suggestions for improvement rather than as simple criticism. Explicit references to prior work and prior IETF discussion should be given whenever possible.
レビューの長さは、状況によって大きく異なる場合があり、I-Dに実質的な改訂が必要であることが明らかな場合、純粋に編集コメントを個人的に送信することは許容できると考えられています。ただし、すべての実質的なコメントは、公開レビューに含める必要があります。可能な限り、コメントは、単純な批判としてではなく、改善の提案として書かれるべきです。可能な限り、以前の作業および以前のIETFディスカッションへの明示的な参照を提供する必要があります。
Reviewers are asked to review for all kinds of problems, such as basic architectural or security issues, Internet-wide impact, technical nits, problems of form and format (such as IANA Considerations or incorrect references), and editorial issues. Since these reviews are on I-Ds that are supposed to be finished, the review should consider "no issue too small" -- but should cover the whole range, from the general architectural level to the editorial level.
レビュー担当者は、基本的なアーキテクチャやセキュリティの問題、インターネット全体の影響、技術的なニット、フォームとフォーマットの問題（IANAの考慮事項や誤った参照など）、編集上の問題など、あらゆる種類の問題を確認するよう求められます。これらのレビューは終了するはずのI-DSに関するものであるため、レビューでは「問題は少なすぎない」と考える必要がありますが、一般的な建築レベルから編集レベルまで、全範囲をカバーする必要があります。
All reviews should apply generally agreed-upon IETF criteria, such as:
すべてのレビューは、次のような合意されたIETF基準を適用する必要があります。
o [RFC1958]: "Architectural Principles of the Internet"
o [RFC1958]：「インターネットの建築原則」
o [RFC3426]: "General Architectural and Policy Considerations"
o [RFC3426]：「一般的な建築と政策の考慮事項」
o [RFC3439]: "Some Internet Architectural Guidelines and Philosophy"
o [RFC3439]：「いくつかのインターネットアーキテクチャガイドラインと哲学」
o ID-Checklist: The "ID checklist" document maintained by the IESG
o ID-CheckList：IESGによって維持されている「IDチェックリスト」ドキュメント
o [RFC2223bis]: "Instructions to Request for Comments (RFC) Authors" as updated by [RFC-STYLE]: "RFC Document Style"
o [RFC2223BIS]：[RFCスタイル]によって更新された「コメントを要求する指示（RFC）著者」：「RFCドキュメントスタイル」
o [RFC5226]: BCP 26 - "Guidelines for Writing an IANA Considerations Section in RFCs"
o [RFC5226]：BCP 26-「RFCSでIANA考慮事項セクションを作成するためのガイドライン」
o [RFC3552]: BCP 72 - "Guidelines for Writing RFC Text on Security Considerations"
o [RFC3552]：BCP 72-「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」
o Any other applicable architectural or procedural documents. It is considered important that reviews give precise references to such criteria when relevant to a comment.
o その他の該当するアーキテクチャまたは手続き文書。レビューがコメントに関連する場合、そのような基準に正確な参照を与えることが重要であると考えられています。
Of special interest to the General area, because they do not fall under any other area, are:
一般的な地域に特に興味深いのは、他のエリアに該当しないため、次のとおりです。
o A clear description of why the I-D or protocol is useful to the Internet.
o I-Dまたはプロトコルがインターネットに役立つ理由の明確な説明。
o Adherence to IETF formalities, such as capitalized "must", "should", etc. in normative statements, per the ID-Checklist.
o ID-CheckListごとに、規範的な声明では、「Must」、「Suff」などのIETF形式への順守。
o Useful and reasonable IANA considerations. Ensure that all necessary registries are defined/referenced, and ensure definition and compliance with IANA assignment criteria.
o 有用で合理的なIANAの考慮事項。必要なすべてのレジストリが定義/参照されていることを確認し、IANAの割り当て基準の定義とコンプライアンスを確保します。
o Correct dependencies for normative references.
o 規範的参照の正しい依存関係。
o That the I-D is written in reasonably clear English.
o I-Dがかなり明確な英語で書かれていること。
o Checking the updates/obsoletes information.
o 更新/廃止情報を確認します。
o Running idnits and checking the output.
o idnitsを実行して出力を確認します。
o Checking that things imported by reference, especially from other RFCs, make sense (notably definitions of terms, security considerations, and lists of criteria) and ensuring they are used as intended by the referenced document.
o 特に他のRFCから参照によってインポートされたものを確認すると、特に用語の定義、セキュリティに関する考慮事項、および基準のリスト）を確認し、参照されたドキュメントで意図したとおりに使用されるようにします。
o That examples (e.g., Fully Qualified Domain Names (FQDNs), telephone numbers, IP addresses) are taken from the right spaces.
o その例（例：完全資格のドメイン名（FQDNS）、電話番号、IPアドレス）は、正しいスペースから取得されます。
The following provides a general overview of the Gen-ART process along with some basic rules associated with assignments. The very precise details of the secretary's process are provided in Section 5.
以下は、Gen-ARTプロセスの一般的な概要と、割り当てに関連するいくつかの基本的なルールを提供します。秘書のプロセスの非常に正確な詳細は、セクション5に記載されています。
o The availability of reviewers and the order of assignments for the next round of Last Call document assignments are updated weekly and are available on the directory where all the assignments and reviews are cached.
o レビュアーの可用性と、最後のコールドキュメント割り当ての次のラウンドの割り当ての順序は毎週更新され、すべての割り当てとレビューがキャッシュされているディレクトリで利用できます。
o At telechat assignment time, all previously reviewed I-Ds are assigned to the reviewer who reviewed them previously, assuming that reviewer is available. Otherwise, these I-Ds are assigned to a new person in the process described below.
o Telechatの割り当て時間に、以前にレビューしたI-DSはすべて、レビュアーが利用可能であると仮定して、以前にレビューしたレビュアーに割り当てられます。それ以外の場合、これらのI-Dは、以下で説明するプロセスで新しい人に割り当てられます。
o The secretary attempts to avoid assigning I-Ds that might conflict with other IETF roles such as WG chairs, other directorates, etc. However, in the cases where the secretary doesn't note the conflict, the reviewer should notify the secretary and Gen-ART mailing list so another reviewer may be assigned.
o 秘書は、WGチェア、他の総局などの他のIETFの役割と競合する可能性のあるI-DSの割り当てを避けようとします。ただし、秘書が紛争に注意していない場合、レビュアーは秘書とGENに通知する必要があります。アートメーリングリストが別のレビュアーに割り当てられる可能性があります。
o It should be emphasized that assignment is never made according to a reviewer's technical specialty. Even though it happens, when, for example, routing I-Ds fall on routing experts or MIB documents fall on MIB doctors, it is coincidental. To the reviewer, the choice looks random.
o レビュアーの技術専門分野に従って割り当てが行われないことを強調する必要があります。たとえば、ルーティングI-DSがルーティングの専門家やMIB文書に該当する場合、MIBの医師に該当する場合、それは偶然です。レビュアーにとって、選択はランダムに見えます。
o There is an attempt to evenly distribute I-Ds amongst reviewers at LC time by using a round-robin process, starting from where the previous week's assignments stopped.
o 前週の課題が停止した場所から始まるラウンドロビンプロセスを使用することにより、LCタイムでレビュー担当者にI-DSを均等に配布する試みがあります。
o Typically, there is no attempt made to actually equalize the load, as the length and complexity of the I-Ds are not taken into account in this process. (Thus, a reviewer could end up with a couple of hundred-page I-Ds, but this is statistically rare.) However, in the case of a reviewer that might receive more than one new LC I-D at one time, the secretary does try to ensure that both are not large I-Ds.
o 通常、このプロセスではI-DSの長さと複雑さが考慮されていないため、実際に負荷を均等化する試みはありません。（したがって、レビュアーは数百ページのI-Dになる可能性がありますが、これは統計的にまれです。）しかし、一度に複数のLC I-Dを受け取るかもしれないレビュアーの場合、秘書はそうします両方が大きなI-DSではないことを確認してください。
o Once the assignments are made, the web pages that list the reviews and the assignments are posted. Since the telechat agenda is not published until the end of the day on the Thursdays prior to the telechats (i.e., one week prior), the secretary needs to complete the assignments on that Thursday evening. This often requires working later in the evening and also requires an Internet connection even when traveling.
o 割り当てが作成されると、レビューと割り当てをリストするWebページが投稿されます。Telechatのアジェンダは、Telechatの前（つまり、1週間前）前の木曜日の1日の終わりまで公開されていないため、秘書はその木曜日の夕方に割り当てを完了する必要があります。これには多くの場合、夕方に動作する必要があり、旅行中でもインターネット接続が必要です。
o If the reviewers notice any problems or conflict of interest, a bargaining process, shifting I-Ds from one reviewer to another, takes place. The secretary updates the assignment files with any new assignments.
o レビュアーが問題や利益相反に気付いた場合、あるレビュアーから別のレビュアーにI-DSをシフトする交渉プロセスが行われます。秘書は、新しい割り当てで割り当てファイルを更新します。
o Once the review has been completed, the reviewer sends the review to the Gen-ART list, ideally using the template provided in the review assignment emails. Typically, reviews are also sent to authors, the responsible AD, and the WG chairs/document shepherd. The only case where this might not be done is when there are no issues found for a re-review and none had been found on an initial review. Sending the review to the authors, ADs, and/or WG chairs/ Proto Shepherds was originally voluntary but is now considered standard practice. Reviewers may also send the reviews to the IETF discussion list, but that is entirely at the discretion of the reviewer, in which case the author must be copied on the review to ensure they see any follow-up discussion. Reviewers may also send the comments to the WG; however, this typically causes the review to end up in the moderation queue, as most reviewers do not want to subscribe to the WG lists for the I-Ds they review. Thus, it is expected that any of the original recipients (i.e., authors, WG chairs/document shepherd, or responsible AD) may forward the review to the WG mailing list if they believe it is necessary. In the past, sending these reviews resulted in confusion among the authors, who may not have been expecting a Gen-ART review and may not be familiar with Gen-ART. Thus, reviewers are reminded to prepend to the email the description of Gen-ART and the purpose of the review. This information is part of the standard template provided in the review assignment emails.
o レビューが完了すると、レビューアはレビューをGen-ARTリストに送信します。理想的には、レビュー割り当てメールで提供されているテンプレートを使用します。通常、レビューは著者、責任ある広告、およびWGチェア/ドキュメントシェパードにも送信されます。これが行われない可能性のある唯一のケースは、リビューの問題が見つからず、最初のレビューで見つかったものがなかった場合です。著者、AD、および/またはWG椅子/ Proto Shepherdsにレビューを送信することは元々自発的でしたが、現在は標準的な慣行と見なされています。レビュアーはレビューをIETFディスカッションリストに送信することもできますが、それは完全にレビュアーの裁量にあります。その場合、著者はレビューでコピーして、フォローアップの議論を確認する必要があります。レビュアーは、コメントをWGに送信することもできます。ただし、これにより、ほとんどのレビュー担当者はレビューするI-DSのWGリストを購読したくないため、これによりレビューがモデレートキューになります。したがって、元の受信者（つまり、著者、WG椅子/文書羊飼い、または責任ある広告）のいずれかが、必要であると思われる場合は、WGメーリングリストにレビューを転送できることが予想されます。過去に、これらのレビューを送信すると、著者の間で混乱が生じました。著者は、Gen-Artのレビューを期待していなかった可能性があり、Gen-Artに精通していない可能性があります。したがって、レビュアーは、Gen-Artの説明とレビューの目的を電子メールに準備することを思い出させます。この情報は、レビュー割り当てメールで提供される標準テンプレートの一部です。
o The secretary gathers the reviews, sometimes edits them for format, and records the review in the spreadsheet on the web pages, including the synopsis. This is typically done on Thursday. This is one aspect of the process that can be easily delegated such that one volunteer uploads all the reviews and then the secretary need only update the fields in the spreadsheet. If the reviewer has not provided a synopsis ("Summary" field in the template), the secretary makes a best guess based on the review details. Note that in most cases the reviewers do include a synopsis.
o 秘書はレビューを収集し、時には形式のためにそれらを編集し、概要を含むWebページのスプレッドシートにレビューを記録します。これは通常、木曜日に行われます。これはプロセスの1つの側面であり、1人のボランティアがすべてのレビューをアップロードし、秘書がスプレッドシートのフィールドを更新する必要があるように、簡単に委任できるようにすることができます。レビュアーが概要（テンプレートの「要約」フィールド）を提供していない場合、秘書はレビューの詳細に基づいて最良の推測を行います。ほとんどの場合、レビュアーには概要が含まれていることに注意してください。
o Ideally, the reviews should be posted to the Gen-ART mailing list by close of business on the East coast on Tuesday. This is necessary to allow the General AD time to consider the reviews prior to the telechat. If the reviews are received after Tuesday, the review may not be read by the AD before the IESG telechat. Due to time constraints, the spreadsheets containing review summaries/assignments are only updated on Thursday evenings when
o 理想的には、レビューは火曜日に東海岸でのビジネスの閉鎖により、Gen-ARTメーリングリストに投稿されるべきです。これは、一般的な広告時間がテレシャットの前にレビューを検討するために必要です。レビューが火曜日以降に受け取られた場合、レビューはIESG Telechatの前に広告によって読まれない場合があります。時間の制約により、レビューの概要/割り当てを含むスプレッドシートは、木曜日の夜にのみ更新されます。
the new LC assignments and upcoming telechat assignments are done. Ideally, the reviews would get uploaded on the Tuesdays prior to the telechat along with the updated spreadsheets.
新しいLCの割り当てと今後のテレシャットの割り当てが完了します。理想的には、レビューは、更新されたスプレッドシートとともに、テレシャットの前の火曜日にアップロードされます。
o If the AD concludes that the concerns raised by the reviewer warrant placing a DISCUSS comment on the I-D, the AD will do so, and the DISCUSS must be resolved before the I-D advances. Usually, the reviewer will be involved in the resolution process, but the responsibility for the DISCUSS rests with the AD.
o 広告が、レビュアーが提起した懸念がi-Dについて議論のコメントを配置すると結論付けた場合、広告はそうし、議論はI-Dが進む前に解決する必要があります。通常、レビュアーは解決プロセスに関与しますが、議論の責任は広告にかかっています。
This section summarizes the details of managing the review materials, including the spreadsheet used to track all reviews and the HTML files containing the review assignments. Please note that these details represent a snapshot of a process that has been implemented -- the details are very likely to change over time, in particular as the needed improvements highlighted in Section 8 are carried out.
このセクションでは、すべてのレビューを追跡するために使用されるスプレッドシートと、レビュー割り当てを含むHTMLファイルを含む、レビュー資料の管理の詳細をまとめたものです。これらの詳細は、実装されたプロセスのスナップショットを表していることに注意してください。特に、セクション8で強調されている必要な改善が実行されるため、詳細は時間とともに変化する可能性が非常に高くなります。
A spreadsheet is used to enter all the I-Ds at the time of assignment and to capture all the reviews. For IETF LC assignments, the assignments are completed before adding the I-Ds to the spreadsheet as described in Section 5.2. For telechat assignments, I-Ds are obviously only added in the cases where there is no previous LC assignment. For the other I-Ds, the appropriate fields are updated as described in Section 5.3.
スプレッドシートは、割り当て時にすべてのI-DSを入力し、すべてのレビューをキャプチャするために使用されます。IETF LCの割り当ての場合、セクション5.2で説明されているように、I-DSをスプレッドシートに追加する前に割り当てが完了します。Telechatの割り当ての場合、I-Dは明らかに、以前のLC割り当てがない場合にのみ追加されます。他のI-DSの場合、セクション5.3で説明されているように、適切なフィールドが更新されます。
All the reviews can be accessed from the spreadsheet via hyperlinks from specific fields, as summarized below. The following information is maintained in the spreadsheet (in the order listed):
以下にまとめたように、すべてのレビューは、特定のフィールドからのハイパーリンクを介してスプレッドシートからアクセスできます。次の情報は、スプレッドシート（リストされている順序で）に維持されています。
1. "Chat/LC Date": Indicates either the date on which the LC review is due or the date of the telechat.
1. 「チャット/LC日付」：LCレビューの期限の日付またはテレシャットの日付を示します。
2. "Document": Filename for the I-D, which includes a hyperlink to the IETF I-D tracker.
2. 「ドキュメント」：IETF I-Dトラッカーへのハイパーリンクを含むI-Dのファイル名。
3. "Assigned": Name of the reviewer assigned to that I-D.
3. 「割り当て」：そのi-dに割り当てられたレビュアーの名前。
4. "Category": This field contains one of the following self-explanatory values: "Doc - WG", "Doc - Ind/AD", or "IETF LC". Note that Gen-ART does not review I-Ds submitted directly to the RFC Editor. The "IETF LC" value is of course entered for all I-Ds at LC time. It is changed to one of the other appropriate values, based on the information in the telechat agenda.
4. 「カテゴリ」：このフィールドには、「Doc -WG」、「doc -ind/ad」、または「ietf lc」の「doc -wg」、「doc -ad」のいずれかが含まれています。Gen-Artは、RFCエディターに直接送信されたI-DSをレビューしないことに注意してください。「IETF LC」値は、もちろんLC時間にすべてのI-DSに入力されます。Telechat Agendaの情報に基づいて、他の適切な値の1つに変更されます。
5. "Previous Review": This includes a link to any previous reviews. For example, when a doc appears on a telechat agenda, if an IETF LC review was done, this field is updated with the review summary for the LC review (i.e., the information from the "Current Review Summary" as described below is copied to this column). The field is set to "New" when an I-D is first assigned/added to the spreadsheet. In the case of returns, this field has a value of "Return" or "Return/IETF-LC" for I-Ds for which there is an LC review. It should be noted that since Gen-ART started doing reviews at LC time, there seem to be far fewer returns on the agenda.
5. 「以前のレビュー」：これには、以前のレビューへのリンクが含まれます。たとえば、ドキュメントがTeleChatのアジェンダに表示される場合、IETF LCレビューが完了した場合、このフィールドはLCレビューのレビュー概要で更新されます（つまり、以下に説明する「現在のレビューの要約」からの情報がコピーされます。この列）。フィールドは、I-Dが最初にスプレッドシートに割り当てられ/追加されたときに「新しい」ように設定されます。リターンの場合、このフィールドには、LCレビューがあるI-DSの「返品」または「Return/IETF-LC」の値があります。Gen-ArtはLC Timeでレビューを開始したため、議題に対するリターンがはるかに少ないように見えることに注意する必要があります。
6. "Current Review Summary": This field includes the review type and version number of the document that is to be reviewed or has been reviewed (e.g., LC: -02). When the field also contains a review summary after the review type/version number (e.g., Telechat: -06 Ready), the active hyperlink points to the review. Occasionally, a reviewer will re-review an I-D prior to its telechat assignment, in which case it is added to the spreadsheet, but the date does not change to maintain consistency in the date field, since the reviews themselves contain the review date.
6. 「現在のレビューの概要」：このフィールドには、レビューされる、またはレビューされているドキュメントのレビュータイプとバージョン番号が含まれています（例：LC：-02）。フィールドにレビュータイプ/バージョン番号の後にレビュー概要が含まれている場合（例：Telechat：-06 Ready）、アクティブなハイパーリンクがレビューを指します。時折、レビュー担当者はテレシャットの割り当ての前にI-Dを再参照します。その場合、スプレッドシートに追加されますが、レビュー自体にレビュー日が含まれているため、日付フィールドの一貫性を維持するために日付は変更されません。
The following summarizes the steps to add a new I-D to the spreadsheet:
以下は、スプレッドシートに新しいI-Dを追加する手順をまとめたものです。
1. In order to optimize steps, blank rows are first inserted for the number of new I-Ds to be added.
1. ステップを最適化するために、ブランク行が最初に追加される新しいI-DSの数に挿入されます。
2. To minimize data entry, a row with default fields (including the hyperlinks) is kept at the end of the file. There is a separate default row for IETF LC versus telechat assignments. This row is copied into each of the new blank rows. The dates are then entered (this allows double-checking that all I-Ds from the review assignments are accounted for, especially LC).
2. データ入力を最小限に抑えるために、ファイルの最後にデフォルトのフィールド（ハイパーリンクを含む）を持つ行が保持されます。IETF LCとTelechatの割り当てには、別のデフォルト行があります。この行は、新しい空白の行のそれぞれにコピーされます。その後、日付が入力されます（これにより、レビュー割り当てからのすべてのI-DSが説明されていること、特にLCを説明することができます）。
3. The I-D name is then copied to the name field as well as being appended to the hyperlink for the "Review Summary" field. The hyperlink is included as part of the default row. This minimizes the steps to enter the reviews in the spreadsheet.
3. i-dの名前は名前フィールドにコピーされ、「レビュー概要」フィールドのハイパーリンクに追加されます。ハイパーリンクは、デフォルトの行の一部として含まれています。これにより、スプレッドシートにレビューを入力する手順が最小限に抑えられます。
4. The data is also sorted by "Chat/LC Date", "Assigned", and "Document". The file is then saved and closed.
4. データは、「チャット/LC日付」、「割り当て」、および「ドキュメント」でもソートされます。その後、ファイルが保存され、閉じられます。
5. The file is then reopened and saved as HTML.
5. その後、ファイルが再開され、HTMLとして保存されます。
6. The file is opened a second time and sorted by "Assigned", "Chat/LC Date", and "Document" to provide the I-D reviewers an easy way to find any outstanding assignments.
6. ファイルは2回目に開かれ、「割り当て」、「チャット/LC日付」、および「ドキュメント」でソートされ、I-Dレビュアーに未解決の課題を見つける簡単な方法を提供します。
The secretary can cache the Last Call assignments as they are announced and/or check the IETF announcement mailing list archives. The assignments are done on Thursday evening, along with any telechat assignments. This optimizes the process in terms of batch changes to files.
秘書は、発表されたときに最後のコール割り当てをキャッシュしたり、IETFアナウンスメーリングリストアーカイブをチェックすることができます。割り当ては木曜日の夕方に行われ、あらゆるテレシャットの割り当てが行われます。これにより、ファイルへのバッチ変更の観点からプロセスが最適化されます。
The assignments are listed in an HTML file. The following are the steps in creating that file:
割り当てはHTMLファイルにリストされています。以下は、そのファイルを作成する手順です。
1. The order of assignment is actually created the week before, with the details below. Thus, before starting the new assignments, the current file is saved for editing for the following week. The current file-naming convention is "reviewersyymmdd-lc.html" (e.g., for July 8th, 2010, the file reviewers100708-lc.html was created, and the file for the following week is named reviewers100715-lc.html).
1. 割り当ての順序は、実際に前の週に作成され、詳細は以下に作成されます。したがって、新しい割り当てを開始する前に、翌週の編集用に現在のファイルが保存されます。現在のファイルアナミング条約は「Recoseersyymmdddddd-lc.html」です（たとえば、2010年7月8日には、ファイルレビュアー100708-LC.htmlが作成され、次の週のファイルはReviewers100715-LC.htmlという名前です）。
2. Since the file is already prepared with the appropriate ordering of reviewers, the assignments are done in the order of due dates. The link to the I-D in the Datatracker is copied into the assignment file along with the intended RFC status for each of the new LC I-Ds.
2. ファイルは既にレビュアーの適切な注文で準備されているため、割り当ては期日の順序で行われます。DataTrackerのI-Dへのリンクは、新しいLC I-DSごとに意図したRFCステータスとともに、割り当てファイルにコピーされます。
3. The "Due Date" paragraph from the Last Call announcement is shortened as follows: "IETF LC ends on:", keeping the date.
3. 最後のコールアナウンスの「期日」の段落は、次のように短縮されます。
4. Once the assignment file is complete, the new I-Ds are added to the spreadsheet as described above.
4. 割り当てファイルが完了すると、上記のように新しいI-DSがスプレッドシートに追加されます。
5. The assignment file for the next week is then updated to reflect the next reviewer in the round-robin process, by simply cutting and pasting the names in the list in a block and removing any "one doc per month" reviewers (annotated with an "*") that have already received their monthly assignment. If the next round of assignments occurs at the beginning of a new month, the "one doc per month" reviewers are added back into the list (in the normal order -- alphabetically by first name).
5. 次に、次の週の割り当てファイルが更新され、ラウンドロビンプロセスの次のレビュー担当者が反映されます。ブロック内のリストの名前を切り取って貼り付けて、「月に1つのドキュメント」レビュアー（注釈が付けられた」レビュアーを削除するだけです。*"）すでに毎月の割り当てを受けています。新しい月の初めに次のラウンドの割り当てが発生した場合、「1か月あたり1つのドキュメント」レビュー担当者がリストに追加されます（通常の順序で - ファーストネームでアルファベット順に）。
6. The assignment files and updated spreadsheets are then cached on the Gen-ART server.
6. 割り当てファイルと更新されたスプレッドシートは、Gen-ARTサーバーでキャッシュされます。
7. An email providing a link to the assignment file along with the updated spreadsheets is sent to the Gen-ART mailing list. This email has a standard form, such that the reviewers can simply cut and paste the template to include the Gen-ART context statement and link to the FAQ.
7. 更新されたスプレッドシートとともに、割り当てファイルへのリンクを提供するメールがGen-ARTメーリングリストに送信されます。このメールには標準フォームがあり、レビュー担当者がテンプレートを単純にカットして貼り付けて、Gen-ARTコンテキストステートメントとFAQへのリンクを含めることができます。
Since LC assignments are now the starting point for Gen-ART I-D reviews, the telechat assignments are generally straightforward, as the majority of the I-Ds are already in the spreadsheet. The following details the steps:
LCの割り当てはGen-Art I-Dレビューの出発点であるため、I-Dの大部分はすでにスプレッドシートにあるため、テレシャットの割り当ては一般に簡単です。次の詳細な手順：
1. The telechat agenda is typically available around 6PM PDT. In order to create the assignment HTML file, the agenda is created from the email announcing the upcoming telechat agenda. The filename has the following format, with the date corresponding to the telechat date (versus the date of assignment, as is the case for Last Call assignments): "reviewersyymmdd.html".
1. 通常、Telechatのアジェンダは午後6時頃に入手できます。割り当てHTMLファイルを作成するために、アジェンダは、今後のTelechatアジェンダを発表する電子メールから作成されます。ファイル名には次の形式があり、日付はテレシャットの日付に対応しています（最後のコール割り当ての場合と同様に、割り当ての日付と同様）「Recoseersyymmdd.html」。
2. Rows are added to the agenda for the reviewers' names.
2. レビュー担当者の名前のアジェンダに行が追加されます。
3. The reviewers' names are then added to the weekly assignment file.
3. レビュー担当者の名前は、毎週の割り当てファイルに追加されます。
4. As each reviewer is added to the assignment file, the review spreadsheet is updated as follows:
4. 各レビュアーが割り当てファイルに追加されると、レビュースプレッドシートは次のように更新されます。
* "Chat/LC Date" is changed to the telechat date.
* 「チャット/LC日付」はテレシャットの日付に変更されます。
* The link to the LC review, if available, is copied as the link for the "Previous Review" column.
* LCレビューへのリンクは、利用可能な場合、「前のレビュー」列のリンクとしてコピーされます。
* The "text" for the "Current Review" is updated to reflect the new review type (i.e., Telechat) and version.
* 「現在のレビュー」の「テキスト」は更新され、新しいレビュータイプ（つまり、テレシャット）とバージョンを反映しています。
5. In the case of an I-D that did not go through IETF LC, a reviewer is assigned using the order in the file to be used for Last Call assignments for the next week.
5. IETF LCを介して行われなかったI-Dの場合、レビュアーは、ファイル内の注文を使用して、来週の最後のコール割り当てに使用されるように割り当てられます。
6. Once the reviewer(s) have been determined, the LC assignment file for the next week is updated.
6. レビュアーが決定されると、来週のLC割り当てファイルが更新されます。
7. Any new I-Ds are then added to the spreadsheet (and the updates saved) per the steps described in Section 5.1.
7. 次に、セクション5.1で説明されている手順に従って、新しいI-DSがスプレッドシート（および更新が保存されている）に追加されます。
8. The assignment files and updated spreadsheets are then cached on the Gen-ART server.
8. 割り当てファイルと更新されたスプレッドシートは、Gen-ARTサーバーでキャッシュされます。
9. An email providing a link to the assignment file along with the updated spreadsheets is sent to the Gen-ART mailing list. This email has a standard form, such that the reviewers can simply cut and paste the template to include the Gen-ART context statement and link to the FAQ.
9. 更新されたスプレッドシートとともに、割り当てファイルへのリンクを提供するメールがGen-ARTメーリングリストに送信されます。このメールには標準フォームがあり、レビュー担当者がテンプレートを単純にカットして貼り付けて、Gen-ARTコンテキストステートメントとFAQへのリンクを含めることができます。
As noted in Section 4.4, the spreadsheet is typically updated with the review summaries on Thursday evenings just prior to entering the data for that week's LC and any telechat assignments. The following summarizes the steps to capture the reviews:
セクション4.4で述べたように、スプレッドシートは通常、その週のLCのデータを入力する直前の木曜日の夕方のレビュー概要とテレシャットの割り当てで更新されます。以下は、レビューをキャプチャする手順をまとめたものです。
1. Currently, an additional volunteer is assisting the secretary in caching the email reviews as they arrive.
1. 現在、追加のボランティアが、到着時に電子メールのレビューをキャッシュするのを支援しています。
2. In the cases where the review is included inline in the body of the email, the review is cut and pasted into a text file and saved with the reviewer's last name appended to the filename -- e.g., draft-ietf-xyz-00-smith.txt.
2. レビューが電子メールの本文にインラインが含まれている場合、レビューはテキストファイルにカットされ、貼り付けられ、ファイル名に追加されたレビュアーの姓（例えば、ドラフト-ITEF-XYZ-00-SMITH）に保存されます。。TXT。
3. In the case where the review is included as an attachment to the email, the file can be directly saved and uploaded.
3. レビューが電子メールへの添付ファイルとして含まれている場合、ファイルは直接保存してアップロードできます。
4. The volunteer uploads the reviews by around 5PM CST on Thursdays; thus, they are available to the secretary at the time that week's assignments are done. This sequence is necessary to ensure the information for I-Ds on the upcoming telechat is up to date.
4. ボランティアは、木曜日に午後5時までレビューをアップロードします。したがって、彼らはその週の任務が完了した時点で秘書に利用可能です。このシーケンスは、今後のテレシャットに関するI-DSの情報が最新であることを確認するために必要です。
5. The review summary is entered into the "Current Summary" field. Note that the hyperlink to the review (added at assignment time) will automatically work when the file is uploaded.
5. レビューの概要は、「現在の概要」フィールドに入力されます。レビューへのハイパーリンク（割り当て時間に追加）は、ファイルがアップロードされたときに自動的に機能することに注意してください。
6. Once all the reviews have been entered and the spreadsheets formatted, the review spreadsheet is saved and files uploaded per the last three steps in Section 5.1.
6. すべてのレビューが入力され、スプレッドシートがフォーマットされると、レビュースプレッドシートが保存され、セクション5.1の最後の3つのステップに従ってファイルがアップロードされます。
Over the past 7 years, the Gen-ART has provided reviewing services to 3 ADs and has done around two thousand publicly available reviews. The reviews have been executed with a team of around a dozen full-time reviewers and other reviewers receiving one I-D assignment each month. There are currently 9 reviewers in the latter category. The full-time reviewers receive 2-3 assignments each month. In terms of improving quality, the number of I-Ds that are now "Ready" at the time of the telechat (since the reviews are now initiated at LC time) has increased. The review term "Ready" means the reviewer believes that the document has no outstanding editorial or technical issues. Based on the data from 2007, there were over 250 I-Ds assigned at LC time that went through IESG review. Of those 250 I-Ds, 82% of the LC reviews (205 I-Ds) were completed. Of the completed reviews, 70% (144 I-Ds) were "Ready" at the time of the telechat. Of those 144 I-Ds, roughly 1/4 had been deemed "Ready" (with no nits) at LC time
過去7年間、Gen-Artは3つの広告にレビューサービスを提供し、約2000人の公開されたレビューを行ってきました。レビューは、毎月1つのI-D割り当てを受けている約12人のフルタイムのレビュアーと他のレビュー担当者のチームで実行されています。現在、後者のカテゴリには9人のレビュアーがいます。フルタイムのレビュアーは毎月2〜3件の課題を受け取ります。品質を改善するという点では、テレシャットの時点で現在「準備ができている」I-Dの数（レビューは現在LC時に開始されているため）が増加しています。レビュー用語「Ready」とは、レビュアーがこの文書には未解決の編集または技術的な問題がないと考えていることを意味します。 2007年のデータに基づいて、IESGレビューを通過したLC時間に250を超えるI-DSが割り当てられました。これらの250 I-DSのうち、LCレビューの82％（205 I-DS）が完了しました。記入済みのレビューのうち、70％（144 I-DS）はテレシャット時に「準備ができていました」。これらの144のI-DSのうち、約1/4がLCの時間に「準備ができていない」とみなされていました
(based on a sample of 50 reviews). For the I-Ds that were not reviewed at LC time, only about 1/4 of those were deemed "Ready" when they were reviewed for the telechat. So, doing the Gen-ART reviews at Last Call time does seem to improve the quality of the I-Ds for the telechat.
（50のレビューのサンプルに基づいています）。LC時間にレビューされなかったI-DSの場合、テレシャットのためにレビューされたときに「準備ができている」とみなされたのは約1/4だけでした。したがって、最後のコールタイムでGen-ARTレビューを行うと、テレシャットのI-DSの品質が向上しているようです。
This section is divided into 3 subsections: the impressions as gathered from the Gen-ART, the impressions of the ADs for whom they worked, and the impressions of the secretaries of Gen-ART.
このセクションは、3つのサブセクションに分かれています。Gen-Artから集められた印象、彼らが働いた広告の印象、Gen-Artの秘書の印象です。
The following list of comments are excerpted and edited from comments sent in by the reviewers of Gen-ART in response to the request:
次のコメントリストは、リクエストに応じてGen-Artのレビュアーから送信されたコメントから抜粋され、編集されています。
"We'd like to ask you each to write a few lines about your personal experience and lessons learned as a Gen-ART reviewer".
「私たちは、あなたの個人的な経験と、gen-artのレビュアーとして学んだ教訓についていくつかの行を書くようにあなたに頼みたいと思います」。
o We really do find problems, but we don't find problems with most I-Ds.
o 私たちは本当に問題を見つけますが、ほとんどのI-DSで問題はありません。
o Comments seem to be in three areas: editorial/grammar, editorial/ what-the-heck-does-this-mean, and actual problems. I'm seeing fewer reviews in the first category, which is a good thing.
o コメントは、編集/文法、編集/ what-the-heck-does-this-mean、および実際の問題の3つの分野にあるようです。最初のカテゴリではより少ないレビューが見られますが、これは良いことです。
o It is becoming rarer that we hear back "these guys have suffered enough; I'm voting no objection" (I'm remembering an LDAP I-D that had been around so long it had 2119 referenced AS A DRAFT -- some people suffered a lot).
o 「これらの人たちは十分に苦しんでいる。私は異議を唱えていない」と聞いているのはより珍しくなりつつある（私は異議を唱えていない」（私は長い間ドラフトとして言及されていた2119があったLDAP I-Dを覚えています - 一部の人々は多くの苦しみをしました）。
o The direct assignment of reviews is necessary and effective. It does not matter much as far as I can tell what scheme is used to actually do the assignment.
o レビューの直接の割り当ては必要かつ効果的です。実際に割り当てを行うためにどのスキームが使用されているかを知ることができる限り、それは問題ではありません。
o Folks are very open to the reviews that come out of Gen-ART. This somewhat surprised me, because I have seen resistance to outside reviews in other cases.
o 人々は、Gen-Artから出てくるレビューに対して非常にオープンです。これはやや驚きました。なぜなら、他のケースで外部のレビューに対する抵抗を見てきたからです。
o The improvements that have come about (for example, one of my latest, an I-D about the SIPPING conference) have made a big difference to the comprehensibility and usability of the I-Ds -- and provide a useful incentive to keep going.
o 発生した改善（たとえば、私の最新の1つであるSipping ConferenceのI-D）は、I-DSの理解と使いやすさに大きな違いをもたらし、続行するための有用なインセンティブを提供します。
o Some form of review like this is desperately needed. While most of the stuff we see is good, every once in a while really bad errors have made their way all the way to IESG vote.
o このような何らかの形のレビューが必死に必要です。私たちが見るもののほとんどは良いことですが、たまに本当にひどいエラーがIESGの投票に進んできました。
o Reading this stuff is interesting. I like having a reason to read a wide range of materials.
o このようなものを読むのは面白いです。私は幅広い材料を読む理由があるのが好きです。
o I am more than convinced that this can be, and is, a valuable process. It is, in my opinion, a pity that Senior IETF Reviewers (SIRS) and so on did not take off, because this late-stage reviewing is a poor substitute for doing the same thing at a much earlier stage. Very few of the drafts that have come past my screen are truly fully ready for IESG review. It is actually a joy to find the occasional nugget that is both well written and is a proper technical job, such that the reviewer really can say "This is ready".
o 私は、これが貴重なプロセスであり、そして価値あるプロセスであると確信しています。私の意見では、上級IETFレビュアー（SIRS）などが離陸しなかったのは残念です。なぜなら、この後期レビューは、はるかに早い段階で同じことをするための貧弱な代替品だからです。私の画面を通過したドラフトのほとんどは、IESGレビューの準備ができていることを本当に完全に準備しています。実際には、よく書かれており、適切な技術的な仕事である時折のナゲットを見つけるのは喜びです。
o I have certainly found the process intellectually stimulating! It encourages me to take a wider interest in what is going on in the IETF, but consumes a fair bit of time to do a proper job, and requires a very wide knowledge to be able to properly catch the cross-area implications: I hope (believe!) that this is something that one gets better at with experience and doing a few of these reviews.
o 私は確かにプロセスが知的に刺激的であることがわかりました！IETFで何が起こっているのかについてより広い関心を引くことを奨励しますが、適切な仕事をするためにかなりの時間を費やし、クロスエリアの意味を適切にキャッチできるために非常に幅広い知識を必要とします。（信じてください！）これは、経験とこれらのレビューのいくつかを行うことで良くなるものであることです。
o There is probably a very limited pool of people who have both the time and the inclination to keep on doing these reviews. It does require a fair bit of dedication.
o おそらく、これらのレビューを続け続ける時間と傾向の両方を持っている人々の非常に限られたプールがあります。かなりの献身が必要です。
o It is difficult to avoid correcting the English, even if that is not really the point: Often, really bad English (whether as a result of non-mother-tongue authors with limited grasp or mother-tongue authors using informal language) obscures/corrupts what is being said or just makes it impossible to read.
o それが実際にはポイントではないとしても、英語を修正することを避けることは困難です。多くの場合、本当に悪い英語（非公開の著者や非公式の言語を使用している母国語の著者の結果として）曖昧/腐敗何が言われているか、または単に読むことを不可能にします。
o Mostly authors welcome the comments: I think most of them understand the concept of "ego-free reviewing", and we have generally been constructive rather than destructive.
o ほとんどの著者はコメントを歓迎します。彼らのほとんどは「自我のないレビュー」の概念を理解していると思います。私たちは一般的に破壊的ではなく建設的でした。
o Part of the job of Gen-ART is to think the unthinkable from another point of view, to challenge (apparently undocumented) assumptions, and apply experience from other fields.
o Gen-Artの仕事の一部は、別の観点から考えられないことを考え、（明らかに文書化されていない）仮定に挑戦し、他の分野から経験を適用することです。
It should be noted that these impressions are from multiple General Area Directors; thus, the "I"s are not necessarily associated with a specific AD.
これらの印象は複数の一般的なエリアディレクターからのものであることに注意する必要があります。したがって、「i」は必ずしも特定の広告に関連付けられているわけではありません。
o It's essential. The reviewing load for the IESG <shout>DOES NOT SCALE</shout>.
o それは不可欠です。IESG <Shout>のレビュー負荷はスケーリングされません</shout>。
o Without Gen-ART, I would be a much less effective General AD.
o Gen-Artがなければ、私ははるかに効果的でない一般的な広告になります。
o On a single fortnight example, the IESG had 21 drafts on the agenda. It is just impossible (to conscientiously review all the documents), and no wonder we sometimes miss serious issues.
o 2週間の例では、IESGには議題に21のドラフトがありました。それは不可能です（すべての文書を誠実にレビューすることは）、そして私たちが深刻な問題を見逃すことがあるのも不思議ではありません。
o So I think a distributed review team with about 30 trusted reviewers needs to be institutionalized. I suspect that will need to be formalized in a BCP sooner or later -- with their reviews having a formal position in the standards process, and the expectation that the whole IESG truly reviews all I-Ds being relaxed.
o したがって、約30人の信頼できるレビュアーを持つ分散レビューチームを制度化する必要があると思います。それは遅かれ早かれBCPで正式化する必要があると思われます - 彼らのレビューは標準プロセスで正式な立場を持っていることであり、IESG全体がすべてのI-Dがリラックスしていることを本当にレビューすることを期待しています。
o We've learned that polite, well reasoned, constructive reviews are very positively received by authors and WGs. Dismissive reviews are counter-productive. And reviews sent in private eventually show up in public, so it's better to go public at the start.
o 私たちは、著名で、十分に理にかなっている建設的なレビューが著者やWGSによって非常に積極的に受け取られていることを学びました。解雇的なレビューは逆効果です。そして、プライベートで送信されたレビューは最終的に公共の場で表示されるため、最初は公開する方が良いでしょう。
o Normally, LC reviews are available in good time for the draft to be revised before reaching the IESG agenda. It is important that this happens, except for an emergency situation where the responsible AD has good reason to place the draft on the agenda immediately. In that case, it would be preferable for the AD to inform the Gen-ART, so that the review can be expedited.
o 通常、LCレビューは、IESGアジェンダに到達する前にドラフトを改訂するのに適した時期に利用できます。責任ある広告がドラフトをすぐに議題に置く正当な理由がある緊急事態を除いて、これが起こることが重要です。その場合、Reviewを迅速化できるように、広告がGen-Artに通知することが望ましいでしょう。
o The other problem is a big detail -- between late Thursday or early Friday when the secretary sends out the assignments, and Wednesday when the General AD likes to start filling in ballots based on the reviews received by close of business on Tuesday, there are only three work days (plus possible volunteer time over the weekend). Now even with only one I-D to review, that may be a real challenge. Sometimes, a lucky reviewer will get 130 pages (e.g., draft-ietf-nntpext-base-27). That doesn't compute.
o もう1つの問題は大きな詳細です - 木曜日の後半または金曜日の金曜日の間に、秘書が割り当てを送るとき、そして水曜日に一般的な広告が火曜日に受け取った営業が受け取ったレビューに基づいて投票に記入を開始するのが好きなとき、3勤務日（さらに、週末のボランティア時間の可能性）。レビューするI-Dが1つだけであっても、それは本当の挑戦かもしれません。幸運なレビュアーが130ページを取得することがあります（例：ドラフト-NNTPEXT-Base-27など）。それは計算しません。
o There are some mechanical issues. The process followed is far too manual. Everything needs to be robotic except for the judgment calls about which reviewer gets which draft. Similarly, the reviewer should be able to just paste the review into a web form, click, and it's sent off to everyone appropriate and posted to the review site.
o いくつかの機械的な問題があります。続くプロセスはあまりにもマニュアルです。どのレビュアーがどのドラフトを取得するかについての判断の呼び出しを除いて、すべてがロボットである必要があります。同様に、レビュアーはレビューをWebフォームに貼り付けてクリックするだけで、適切なすべての人に送られてレビューサイトに投稿できるはずです。
Serving as the secretary of Gen-ART is a worthwhile experience. From a personal point of view, it gives the secretary an easy way to track all of the work going through the IESG review process and see how the work flowed through that process. Also, by reviewing and sometimes creating the one-line abstracts that go on the review web page, the secretary has an opportunity to really get a survey of the work being approved by the IETF.
Gen-Artの秘書を務めることは価値のある経験です。個人的な観点からは、IESGレビュープロセスを通過しているすべての作業を追跡し、そのプロセスをどのように流れているかを確認するための簡単な方法を秘書に与えます。また、レビューWebページに掲載されているワンラインの要約をレビューし、時には作成することにより、秘書はIETFによって承認されている作業の調査を実際に取得する機会があります。
The nature of these reviews is informal, and originally the reviews were only intended for the General AD, though they were made public. During 2004, there was little if any interaction between authors and reviewers. There was some discussion during 2004 about trying to expand the role of Gen-ART to a more formal, early-review model, i.e., to evolve it into a form of SIRS. The original Gen-ART secretary was against such a transformation, because she felt it would put at risk something that worked. She believed that there were risks inherent in formalizing the reviews and adding mechanisms for standardizing the resultant review process. Another concern involves the interaction between reviewers and authors. As discussed above, it has become the practice to send reviews to the authors with an explanation about the nature of Gen-ART reviews. While it is clear that this has resulted in improved RFCs, it has also resulted in increased workload for the reviewers.
これらのレビューの性質は非公式であり、もともとレビューは一般的な広告を目的としていましたが、公開されていました。2004年には、著者とレビュアーの間にはほとんどやり取りがあったとしてもほとんどありませんでした。2004年に、Gen-Artの役割をより正式な早期レビューモデルに拡大しようとすることについて、つまりSIRSの形に進化しようとすることについて議論がありました。元のgen-art秘書は、そのような変容に反対していました。彼女は、結果のレビュープロセスを標準化するためのレビューの形式化とメカニズムを追加することにはリスクがあると信じていました。別の懸念には、レビュアーと著者の間の相互作用が含まれます。上記で説明したように、Gen-ARTレビューの性質について説明して、著者にレビューを送信することが実践になりました。これによりRFCが改善されたことは明らかですが、レビュアーのワークロードが増加しました。
The secretary thinks that Gen-ART is an experiment that works well, but she also believes it is fragile. The secretary is often concerned about overburdening reviewers, and feels it is her responsibility to keep them from burning out. Adding additional reviewers to the review team would help to alleviate this concern. In terms of the process, adding additional reviewers has minimal impact.
秘書は、Gen-Artはうまく機能する実験であると考えていますが、彼女はそれが壊れやすいとも信じています。秘書はしばしば、レビュアーの負担を負うことを心配しており、彼らが燃え尽きるのを防ぐことは彼女の責任であると感じています。レビューチームに追加のレビュアーを追加すると、この懸念を軽減するのに役立ちます。プロセスに関しては、追加のレビュー担当者を追加することで最小限の影響があります。
The current size of the review team introduces a fairly heavy workload for the individual reviewers that are not on the "one doc per month" assignment cycle. Additional reviewers would be really helpful to alleviate this workload. It is also important to note that having additional reviewers adds minimal workload to the
レビューチームの現在のサイズは、「1か月あたり1つのドキュメント」割り当てサイクルにない個々のレビュアーにかなり重いワークロードを導入します。追加のレビュー担当者は、このワークロードを軽減するのに本当に役立ちます。また、追加のレビュアーを持つことで最小限のワークロードが追加されることに注意することも重要です。
secretary's process; thus, the only blocking point is finding the right folks that are interested in this type of volunteer role. As noted in Section 7.2, 30 would be a good size for the review team. This would cut the workload for an individual reviewer in half (given the current model of 9 reviewers on the "one doc per month" assignment cycle).
秘書のプロセス;したがって、唯一のブロッキングポイントは、このタイプのボランティアの役割に関心のある適切な人々を見つけることです。セクション7.2で述べたように、30はレビューチームにとって良いサイズです。これにより、個々のレビュアーのワークロードが半分に削減されます（「1か月あたり1つのドキュメント」割り当てサイクルに関する9人のレビュアーの現在のモデルが与えられます）。
Obviously, automation of the process would be a good thing. However, Gen-ART secretaries are not necessarily highly motivated to transition to a more automated approach until a significant part of the process is automated. In more recent consideration of this situation, it likely would be best to first automate the process of entering the reviews, as that benefits the review team as a whole. This automation should allow the reviewers to enter the reviews via a web interface that would automatically generate the appropriate emails -- quite similar to how the draft "Upload" tool currently works. Also, given consistent naming conventions for the review forms, this step would automate some of the process for the secretary, as the reviews would automatically appear via the spreadsheet hyperlinks, although there would still be a need to manually enter the summary. But this would eliminate the need to edit/normalize and upload files and, hopefully, eliminate the problem encountered with unflowed text in emails and getting the review properly formatted using some text editors.
明らかに、プロセスの自動化は良いことです。ただし、Gen-ART秘書は、プロセスの重要な部分が自動化されるまで、より自動化されたアプローチへの移行に必ずしも意欲的ではありません。この状況をより最近の検討において、レビューチーム全体に利益をもたらすため、最初にレビューの入力プロセスを自動化することが最善でしょう。この自動化により、レビュアーは、適切な電子メールを自動的に生成するWebインターフェイスを介してレビューを入力できるようにする必要があります。これは、ドラフトの「アップロード」ツールの動作と非常によく似ています。また、レビューフォームの一貫した命名規則を考えると、このステップは、レビューがスプレッドシートハイパーリンクを介して自動的に表示されるため、秘書のプロセスの一部を自動化しますが、概要を手動で入力する必要があります。ただし、これにより、ファイルを編集/正規化およびアップロードする必要性がなくなり、メールで未処理のテキストで発生した問題を排除し、一部のテキストエディターを使用してレビューを適切にフォーマットします。
Section 5 was written to facilitate the process of determining tools requirements, by providing the very detailed steps currently applied to the process. As noted above, automating the upload of the reviews could be a good first step. This is somewhat starting at the end of the process. However, it seems that by automating in this direction, we may have optimal results; since one of the earliest steps in the process is the task of assigning reviewers, it likely needs the most manual intervention, even with tools available.
セクション5は、現在プロセスに適用されている非常に詳細な手順を提供することにより、ツール要件を決定するプロセスを促進するために書かれています。上記のように、レビューのアップロードを自動化することは、良い最初のステップになる可能性があります。これは、プロセスの終わりからやや始まります。ただし、この方向に自動化することにより、最適な結果が得られるようです。プロセスの最も早いステップの1つはレビュアーを割り当てるタスクであるため、利用可能なツールを使用しても、最も手動で介入する必要がある可能性があります。
The current SecDir secretary does use some tools for assignments and generating assignment emails. These tools could be considered for use by the Gen-ART secretary. Since the SecDir reviews are not cached and the information maintained for those reviews is less detailed, there would be no reusability of that aspect. However, if the Gen-ART spreadsheet can be automatically populated (with assignments and completed reviews), the SecDir may be able to make use of that same tool.
現在のSecdir秘書は、割り当ておよび割り当てメールを生成するためにいくつかのツールを使用しています。これらのツールは、Gen-ART秘書が使用することを考慮することができます。Secdirのレビューはキャッシュされておらず、これらのレビューのために維持されている情報はあまり詳細ではないため、その側面の再利用性はありません。ただし、Gen-ARTスプレッドシートを自動的に入力できる場合（割り当てと完了したレビューを使用して）、Secdirは同じツールを利用できる場合があります。
As implemented today, the process has no formal role in the IETF standards process. But as trust in the review team has built, and as the team itself has learned to deliver reviews that are generally well received, they have had a significant impact on I-D quality and on timeliness. Rather than becoming a roadblock, they have (in general) allowed the General AD to feel more confident in reaching decisions and be more precise in resolving issues. Since reviews now typically appear during IETF Last Call, the reviews, like the SecDir reviews, are now generally expected. So, the role of the team has evolved to be more formal than in the past (i.e., when this document was first drafted in 2005). However, the handling of the reviews remains entirely within the scope of the ADs, document shepherds, WG chairs, and authors as they deem appropriate.
今日実装されているように、このプロセスはIETF標準プロセスに正式な役割を果たしていません。しかし、レビューチームへの信頼が構築されており、チーム自体が一般的に好評のレビューを提供することを学んだので、I-Dの品質と適時性に大きな影響を与えました。障害になるのではなく、（一般的に）一般的な広告が意思決定に到達することに自信を持ち、問題を解決するのがより正確になることを許可しました。レビューは通常、IETFの最後の呼び出し中に表示されるため、Secdirのレビューと同様に、レビューが一般的に予想されています。したがって、チームの役割は、過去よりもフォーマルになるように進化しました（つまり、このドキュメントが2005年に最初に起草されたとき）。ただし、レビューの取り扱いは、広告、文書羊飼い、WG椅子、および著者が適切と思われる著者の範囲内に完全に依存しています。
Since this is an informational I-D about an open process, the security considerations are specific to the process and users involved in the process. The primary concern would be to limit the people that have the ability to create and update the Gen-ART data/ files to ensure that the integrity of the data is maintained. For example, each Gen-ART reviewer should have a unique user name/ password, just as folks do to access any other IETF-maintained data, as appropriate.
これはオープンプロセスに関する情報IDであるため、セキュリティ上の考慮事項はプロセスとプロセスに関与するユーザーに固有です。主な関心事は、Gen-Artデータ/ファイルを作成および更新して、データの整合性が維持されるようにする能力を制限することです。たとえば、各Gen-ARTレビューアは、他のIETFに維持されたデータに必要に応じてアクセスするために行うように、一意のユーザー名/パスワードを持つ必要があります。
Initial comments were received from the members of the Gen-ART, and the experiences discussed in this document were derived from their hard work over the last 7+ years. We thank the past reviewers of the Gen-ART:
Gen-Artのメンバーから最初のコメントが受け取られ、この文書で議論された経験は、過去7年間の努力から派生しました。Gen-Artの過去のレビュアーに感謝します。
Mark Allman Harald Alvestrand (creator of Gen-ART) Ron Bonica Scott Brim Gonzalo Camarillo Sharon Chisholm Spencer Dawkins Lakshminath Dondeti Avri Doria (past secretary) Pasi Eronen Dorothy Gellert Eric Gray Avashalom Houri Glenn Kowack
マーク・オールマン・ハラルド・アルベスランド（Gen-Artの作成者）Ron Bonica Scott Brim Gonzalo Camarilo Camarilo Sharolm Chisholm Spencer Dawkins Lakshminath Dondeti Avri Doria（過去秘書）Pasi Eronen Dorothy Gellert Eric Avashalom
John Loughney Lucy Lynch Enrico Marocco Michael Patton Stefan Santesson Robert Sparks Tom Taylor Sean Turner Christian Vogt Suzanne Woolf
ジョン・ラフニー・ルーシー・リンチ・エンリコ・マロッコ・マイケル・パットン・ステファン・サンテソン・ロバート・スパークストム・テイラー・ショーン・ターナー・ヴォッグ・スザンヌ・ウルフ
We also thank the current team of reviewers/secretary:
また、現在のレビュアー/秘書のチームに感謝します。
Mary Barnes (past secretary, 2005-2010) Richard Barnes David Black Ben Campbell Brian Carpenter (past General AD) Elwyn Davies Francis Dupont Roni Even Miguel-Angel Garcia Vijay Gurbani (assisting secretary to upload reviews) Wassim Haddad Joel Halpern Suresh Krishnan Peter McCann Jean Mahoney (secretary as of Jan. 2011) Alexey Melnikov Kathleen Moriarty
メアリー・バーンズ（過去の秘書、2005年から2010年）リチャード・バーンズ・バーンズ・ブラック・ベン・キャンベル・ブライアン・カーペンター（過去の広告）エルウィン・デイビス・フランシス・デュポン・ロニさえミゲル・アンジェル・ガルシア・ヴィジェイ・ガーバニ（アップロードレビューを支援する）ジャン・マホニー（2011年1月の秘書）アレクセイ・メルニコフ・キャスリーン・モリアーティ
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2223bis] Reynolds, J., Ed., and R. Braden, Ed., "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[RFC2223bis] Reynolds、J.、ed。、およびR. Braden、ed。、「コメント要求の指示（RFC）著者」、2004年8月、進行中の作業。
[RFC-STYLE] Braden, R., Ginoza, S., and A. Hagens, "RFC Document Style", September 2009, <http://www.rfc-editor.org/rfc-style-guide/rfc-style>.
[RFCスタイル] Braden、R.、Ginoza、S。、およびA. Hagens、「RFC Document Style」、2009年9月、<http://www.rfc-editor.org/rfc-style-guide/rfc--スタイル>。
[RFC3426] Floyd, S., "General Architectural and Policy Considerations", RFC 3426, November 2002.
[RFC3426]フロイド、S。、「一般的な建築と政策の考慮事項」、RFC 3426、2002年11月。
[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural Guidelines and Philosophy", RFC 3439, December 2002.
[RFC3439] Bush、R。およびD. Meyer、「いくつかのインターネットアーキテクチャガイドラインと哲学」、RFC 3439、2002年12月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[SIRS] Carpenter, B. and D. Crocker, "Careful Additional Review of Documents (CARD) by Senior IETF Reviewers (SIRS)", Work in Progress, June 2003.
[Sirs] Carpenter、B。およびD. Crocker、「シニアIETFレビュアー（SIRS）によるドキュメント（カード）の注意深い追加レビュー（SIRS）」、2003年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Mary Barnes Polycom TX USA
メアリーバーンズポリコムテキサスUSA
EMail: mary.ietf.barnes@gmail.com
Avri Doria Research Consultant Providence, RI USA
Avri Doria Research Consultant Providence、Ri USA
EMail: avri@acm.org
Harald Alvestrand Google Kungsbron 2 11122 Stockholm SE
Harald Alvestrand Google Kungsbron 2 11122 Stockholm SE
EMail: harald@alvestrand.no
Brian E. Carpenter University of Auckland PB 92019 Auckland, 1142 New Zealand
ブライアンE.カーペンター大学オークランドPB 92019オークランド、1142ニュージーランド
Phone: EMail: brian.e.carpenter@gmail.com
電話：電子メール：Brian.E.Carpenter@gmail.com