RFC1603 日本語訳
1603 IETF Working Group Guidelines and Procedures. E. Huizer, D.Crocker. March 1994. (Format: TXT=63900 bytes) (Obsoleted by RFC2418) (Updated by RFC1871) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E. Huizer
Request for Comments: 1603 SURFnet bv
Category: Informational D. Crocker
Silicon Graphics, Inc.
March 1994
Huizerがコメントのために要求するワーキンググループE.をネットワークでつないでください: 1603SURFnet bv Category: 1994年の情報のD.医者シリコングラフィックスの行進
IETF Working Group
Guidelines and Procedures
IETFワーキンググループガイドラインと手順
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined.
インターネット・エンジニアリング・タスク・フォース(IETF)には、インターネットStandardsとして意図する仕様を開発して、再検討することへの責任があります。 IETF活動はワーキンググループ(WGs)に組織化されます。 このドキュメントはIETFワーキンググループの構成と操作のためのガイドラインと手順について説明します。 それはIETF関係者WGとインターネットEngineering Steering Group(IESG)との正式な関係について説明します。 IETF関係者の基本任務であり、WGを含んでいて、議長とIESG Areaディレクターは定義されます。
Table of Contents
目次
1. INTRODUCTION.............................................. 2
1.1. IETF approach to standardization........................ 3
1.2. Acknowledgments......................................... 4
2. WORKING GROUP (WG) FORMATION.............................. 5
2.1. Criteria for formation.................................. 5
2.2. Charter................................................. 6
2.3. Charter review & approval............................... 9
2.4. Birds of a feather (BOF)................................ 9
3. WORKING GROUP OPERATION................................... 11
3.1. Session planning........................................ 11
3.2. Session venue........................................... 12
3.3. Session management...................................... 14
3.4. Contention and appeals overview......................... 15
4. WORKING GROUP TERMINATION................................. 16
5. STAFF ROLES............................................... 17
5.1. WG Chair................................................ 17
5.2. WG Editor/Secretary..................................... 19
5.3. WG Facilitator.......................................... 19
5.4. Design teams............................................ 19
1. 序論… 2 1.1. IETFは標準化にアプローチします… 3 1.2. 承認… 4 2. 作業部会(WG)の構成… 5 2.1. 構成の評価基準… 5 2.2. チャーターします。 6 2.3. 憲章レビューと承認… 9 2.4. 羽(BOF)の鳥… 9 3. ワーキンググループ操作… 11 3.1. セッション計画… 11 3.2. セッション開催地… 12 3.3. セッション管理… 14 3.4. 主張と上告概観… 15 4. ワーキンググループ終了… 16 5. 役割を配置してください… 17 5.1. WG議長… 17 5.2. WGエディタ/長官… 19 5.3. WGまとめ役… 19 5.4. チームを設計してください… 19
Huizer & Crocker [Page 1] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[1ページ]RFC1603IETFワーキンググループガイドライン行進1994
5.5. Area Consultant......................................... 19
5.6. Area Director........................................... 20
5.7. Area Directorate........................................ 21
6. WORKING GROUP DOCUMENTS................................... 21
6.1. Session documents....................................... 21
6.2. IETF meeting document archive........................... 21
6.3. Internet-Drafts (I-D)................................... 23
6.4. Request For Comments (RFC).............................. 24
6.5. Submission of documents................................. 24
6.6. Review of documents..................................... 25
7. SECURITY CONSIDERATIONS................................... 26
8. REFERENCES................................................ 26
9. AUTHORS' ADDRESSES........................................ 27
APPENDIX: SAMPLE WORKING GROUP CHARTER........................ 28
5.5. 領域のコンサルタント… 19 5.6. 領域のディレクター… 20 5.7. 領域の管理職… 21 6. ワーキンググループドキュメント… 21 6.1. セッションドキュメント… 21 6.2. IETFミーティングドキュメントアーカイブ… 21 6.3. インターネット草稿(I-D)… 23 6.4. コメント(RFC)のために、要求します。 24 6.5. ドキュメントの提出… 24 6.6. ドキュメントのレビュー… 25 7. セキュリティ問題… 26 8. 参照… 26 9. 作者のアドレス… 27付録: ワーキンググループ特許を抽出してください… 28
1. INTRODUCTION
1. 序論
This document defines guidelines and procedures for Internet Engineering Task Force working groups. The Internet is a loosely- organized international collaboration of autonomous, interconnected networks; it supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards, a collection of which are commonly known as "the TCP/IP protocol suite". The Internet Standards Process is defined in [1]. Development and review of potential Internet Standards from all sources is conducted by the Internet Engineering Task Force (IETF).
このドキュメントはインターネット・エンジニアリング・タスク・フォースワーキンググループのためにガイドラインと手順を定義します。 インターネットは自治の、そして、インタコネクトされたネットワークの緩く組織化された国際協力です。 それは開くインターネットStandards、収集で定義されたそれのプロトコルと手順が「TCP/IPプロトコル群」として一般的に知られている自発的の固守でホスト間通信を支持します。 インターネットStandards Processは[1]で定義されます。 すべてのソースからの潜在的インターネットStandardsの開発とレビューがインターネット・エンジニアリング・タスク・フォース(IETF)によって行われます。
The IETF is a large, open community of network designers, operators, vendors, users, and researchers concerned with the Internet and the technology used on it. The IETF is managed by its Internet Engineering Steering Group (IESG) whose membership includes an IETF Chair, responsible for oversight of general IETF operations, and Area Directors, each of whom is responsible for a set of IETF activities and working groups. The IETF Executive Director and IESG Secretary are ex-officio participants, as are the IAB Chair and a designated Internet Architecture Board (IAB) member. At present there are 10 areas, though the number and purview of areas changes over time:
IETFはそれで使用されるインターネットと技術に関するネットワーク設計者、オペレータ、業者、ユーザ、および研究者の大きくて、開いている共同体です。 IETFは会員資格がIETF議長を含んでいるインターネットEngineering Steering Group(IESG)によって管理されます、一般的なIETF操作、およびAreaディレクターの見落としに責任があります。それはそれぞれ1セットのIETF活動とワーキンググループに原因となります。 IETF専務とIESG長官は元のofficio関係者です、IAB議長と指定されたインターネット・アーキテクチャ委員会(IAB)のメンバーのように。 現在のところ、領域変化の数と範囲ですが、時間がたつにつれて、10の領域があります:
User Services (USV)
Applications (APP)
Service Applications (SAP)
Transport Services (TSV)
Internet (INT)
Routing (RTG)
Network Management (MGT)
Operational Requirements (OPS)
Security (SEC)
Standards & Processes (STD)
ユーザサービス(USV)アプリケーション(装置)サービスアプリケーション(SAP)輸送サービス(TSV)インターネット(INT)ルート設定(RTG)ネットワークマネージメント(MGT)の操作上の要件(オプアート)セキュリティ規格と過程(SEC)(STD)
Huizer & Crocker [Page 2] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[2ページ]RFC1603IETFワーキンググループガイドライン行進1994
Most areas have an advisory group or directorate. The specific name and the details of the role for each group differs from area to area, but the primary intent is that the group assist the Area Director, e.g., with the review of specifications produced in the area. An advisory group is formed by an Area Director (AD) and comprises experienced members of the IETF and technical community represented by the area. A small IETF Secretariat provides staff and administrative support for the operation of the IETF.
ほとんどの領域には、顧問団か管理職がいます。 各グループのための役割の種名と詳細は領域から領域まで異なりますが、第一の意図はグループがAreaディレクターを補助するということです、例えば、仕様のレビューがその領域で製作されている状態で。 顧問団は、Areaディレクター(AD)によって形成されて、領域によって代表されたIETFと技術的な共同体の経験豊富なメンバーを包括します。 小さいIETF事務局はスタッフと管理サポートをIETFの操作に提供します。
The primary activities of the IETF are performed by committees known as working groups. There are currently more than 60 of these. Working groups tend to have a narrow focus and a lifetime bounded by completion of a specific task, although there are exceptions.
IETFの第一の活動はワーキンググループとして知られている委員会によって実行されます。 現在、これらの60以上があります。 ワーキンググループは、狭い焦点を持っている傾向があります、そして、寿命は特定のタスクの完成でバウンドしました、例外がありますが。
There is no formal membership in the IETF. Participation is open to all. This participation may be by on-line contribution, attendance at face-to-face sessions, or both. Anyone from the Internet community who has the time and interest is urged to participate in IETF meetings and any of its on-line working group discussions. Participation is by individual technical contributors, rather than by formal representatives of organizations.
どんな正式な会員資格もIETFにありません。 参加はすべてに開かれています。 この参加はオンライン貢献、面と向かっているセッションの出席、または両方であるかもしれません。 インターネットコミュニティからの時間と関心を持っているだれでもIETFミーティングとオンラインワーキンググループ議論のどれかに参加するよう促されます。 参加が組織の公式代表でというよりむしろ個々の技術貢献者のそばにあります。
This document defines procedures and guidelines for formation and operation of working groups in the IETF. It defines the relations of working groups to other bodies within the IETF. The duties of working group Chairs and Area Directors with respect to the operation of the working group are also defined. The document uses: "shall", "will", "must" and "is required" where it describes steps in the process that are essential, and uses: "suggested", "should" and "may" are where guidelines are described that are not essential, but are strongly recommended to help smooth WG operation.
このドキュメントはIETFでのワーキンググループの構成と操作のための手順とガイドラインを定義します。 それはIETFの中の他のボディーとワーキンググループの関係を定義します。 また、ワーキンググループの操作に関するワーキンググループChairsとAreaディレクターの義務は定義されます。 ドキュメントは以下を使用します。 "shall"、“will"、“must"、過程における不可欠のステップについて説明するところで「必要であり」、以下を使用します。 「示され」て、“should"と“may"は不可欠でないガイドラインが説明されるところですが、滑らかなWG操作を助けることが強く勧められます。
1.1. IETF approach to standardization
1.1. 標準化へのIETFアプローチ
The reader is encouraged to study The Internet Standards Process [1]. Familiarity with this document is essential for a complete understanding of the philosophy, procedures and guidelines described in this document.
読者がインターネットStandards Process[1]を研究するよう奨励されます。 本書では説明された哲学、手順、およびガイドラインの完全な理解に、このドキュメントへの親しみは不可欠です。
The goals of the process are summarized in [1]:
過程の目標は[1]にまとめられます:
"In general, an Internet Standard is a specification that is
stable and well-understood, is technically competent, has
multiple, independent, and interoperable implementations
with operational experience, enjoys significant public
support, and is recognizably useful in some or all parts of
the Internet.
...
「一般に、インターネットStandardは安定した仕様であり、よく分かって、技術的に有能であり、運用経験による複数の、そして、独立していて、共同利用できる実現を持って、重要な公的支援を楽しんで、インターネットのいくつかかすべての地域で認識可能に役に立ちます。」 ...
Huizer & Crocker [Page 3] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[3ページ]RFC1603IETFワーキンググループガイドライン行進1994
"In outline, the process of creating an Internet Standard is
straightforward: a specification undergoes a period of
development and several iterations of review by the Internet
community and perhaps revision based upon experience, is
adopted as a Standard by the appropriate body (see below),
and is published.
「アウトラインでは、インターネットStandardを作成する過程は簡単です」 仕様は、インターネットコミュニティと恐らく経験に基づく改正で開発の一区切りとレビューのいくつかの繰り返しを受けて、Standardとして適切なボディー(以下を見る)によって採用されて、発表されます。
"In practice, the process is somewhat more complicated, due
to (1) the number and type of possible sources for
specifications; (2) the need to prepare and revise a
specification in a manner that preserves the interests of
all of the affected parties; (3) the importance of
establishing widespread community agreement on its technical
content; and (4) the difficulty of evaluating the utility of
a particular specification for the Internet community.
...
"These procedures are explicitly aimed at developing and
adopting generally-accepted practices. Thus, a candidate
for Internet standardization is implemented and tested for
correct operation and interoperability by multiple,
independent parties, and utilized in increasingly demanding
environments, before it can be adopted as an Internet
Standard."
「実際には、過程は(1) 仕様のための可能なソースの数とタイプのためにいくらか複雑です」。 (2) 影響を受けた当事者のすべての関心を保存する方法による仕様を準備して、改訂する必要性。 (3) 技術的な内容の広範囲の共同体協定を確立する重要性。 (4) そして、インターネットコミュニティのための特記仕様書に関するユーティリティを評価するという困難。 ... 「これらの手順は明らかに一般に慣例を開発して、採用するのを目的とされます。」 「その結果、インターネット標準化の候補は、正しい操作と相互運用性がないかどうか複数の、そして、独立しているパーティーによって実行されて、テストされて、ますます環境を要求する際に利用されます、インターネットStandardとしてそれを採用できる前に。」
The IETF standardization process has been marked by informality. As the community of participation has grown it has become necessary to document procedures, while continuing to avoid unnecessary bureaucracy. This goals of this balancing act are summarized in [1] as:
IETF標準化過程は非公式によってマークされました。 参加の共同体が発展するのに従って、不要な官僚制度を避け続けている間、それはドキュメント手順に必要になっています。 この収支裁決のこの目標は以下として[1]にまとめられます。
"The procedures that are described here provide a great deal
of flexibility to adapt to the wide variety of circumstances
that occur in the Internet standardization process.
Experience has shown this flexibility to be vital in
achieving the following goals for Internet standardization:
「ここで説明される手順はインターネット標準化過程で現れる広いバラエティーの事情に順応するために多くの柔軟性を提供します。」 経験は、この柔軟性がインターネット標準化の以下の目標を達成するのにおいて重大であることを示しました:
* high quality,
* prior implementation and testing,
* openness and fairness, and
* timeliness."
* 「高い品質、*先の実現、テスト、*風通しの良さ、公正、および*タイムリーさである。」
1.2. Acknowledgments
1.2. 承認
Much of this document is due to the copy-and-paste function of a word processor. Several passages have been taken from the documents cited in the reference section. The POISED WG provided discussion and comments. Three people deserve special mention, as especially large chunks of their documents have been integrated into this one: Vint
このドキュメントの多くがワードプロセッサのコピーとペーストの機能のためです。 いくつかの通路が参照部で引用されたドキュメントから抜粋されました。 POISED WGは議論とコメントを提供しました。 それらのドキュメントの特に大きい塊がこれと統合されたとき、3人の人が特記に値します: Vint
Huizer & Crocker [Page 4] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[4ページ]RFC1603IETFワーキンググループガイドライン行進1994
Cerf [7] from whom we borrowed the description of the IETF; and Greg Vaudreuil and Steve Coya who provided several paragraphs. Also, John Stewart and Steve Crocker did a truly stellar job of proof-reading. However, all the errors you'll find are probably ours.
私たちがIETFの記述を借りたサーフ[7]。 数個のパラグラフ提供したグレッグ・ボードルイとスティーブCoya。 また、ジョン・スチュワートとスティーブ・クロッカーはプルーフ・リーディングの本当に星の仕事をしました。 しかしながら、あなたが見つけるすべての誤りがたぶん私たちのものです。
2. WORKING GROUP (WG) FORMATION
2. 作業部会(WG)の構成
IETF working groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended as standards or recommendations. A working group may be established at the initiative of an Area Director (AD) or it may be initiated by an individual or group of individuals. Anyone interested in creating an IETF working group must obtain the advice and consent of the appropriate IETF Area Director under whose direction the working group would fall and must proceed through the formal steps detailed in this section.
IETFワーキンググループ(WGs)はIETF仕様とガイドラインの開発のための一次機構です。その多くが規格か推薦として意図します。 ワーキンググループがAreaディレクター(AD)のイニシアチブのときに設立されるかもしれませんか、またはそれは個人か個体群によって開始されるかもしれません。 IETFワーキンググループを創設したがっていただれでも、ワーキンググループが指示に基づき落ちる適切なIETF Areaディレクターの助言と同意を得なければならなくて、このセクションで詳細な正式なステップで続かなければなりません。
A working group is typically created to address a specific problem or produce a deliverable (a guideline, standards specification, etc.) and is expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group as a unit is terminated. Alternatively at the discretion of the IESG, Area Director, the WG Chair and the WG participants, the objectives or assignment of the working group may be extended by enhancing or modifying the working group's charter.
ワーキンググループは、その特定の問題を訴えるか、または提出物(ガイドライン、規格仕様など)を生産するために通常創設されて、現実に短命であると予想されます。 目標の完成と目的の達成のときに、ワーキンググループは一体にして終えられます。 あるいはまた、IESGの裁量では、ワーキンググループのAreaディレクターかWG議長とWG関係者か、目的か課題が、ワーキンググループの特許を機能アップするか、または変更することによって、敷衍されるかもしれません。
2.1. Criteria for formation
2.1. 構成の評価基準
When determining whether it is appropriate to create a working group, the Area Director and the IESG will consider several issues:
ワーキンググループを創設するのが適切であるかどうか決定するとき、AreaディレクターとIESGはいくつかの問題を考えるでしょう:
- Are the issues that the working group plans to address clear
and relevant for the Internet community?
- ワーキンググループが計画している問題はインターネットコミュニティにおいて、明確で関連しているアドレスですか?
- Are the goals specific and reasonably achievable, and
achievable within the time frame specified by the
milestones?
- 時間枠の中で特定の、そして、合理的に達成可能で、達成可能な目標は重大事件で指定されますか?
- What are the risks and urgency of the work, to determine the
level of attention required?
- 仕事のリスクと緊急は、注意のレベルが必要であることを決定するためには何ですか?
- Do the working group's activities overlap with those of
another working group? If so, it may still be appropriate to
create the working group, but this question must be
considered carefully by the Area Directors as subdividing
efforts often dilutes the available technical expertise.
- ワーキンググループの活動は別のワーキンググループのものに重なりますか? そうだとすれば、それは、ワーキンググループを創設するのがまだ適切であるかもしれませんが、しばしば努力を細分するとしてのAreaディレクターで慎重に利用可能な技術的専門知識を希釈しますこの質問を考えなければならない。
Huizer & Crocker [Page 5] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[5ページ]RFC1603IETFワーキンググループガイドライン行進1994
- Is there sufficient interest and expertise in the working
group's topic with at least several people willing to expend
the effort to produce the desired result (e.g., a protocol
specification)? Working groups require considerable effort,
including management of the working group process, editing
of working group documents, and contribution to the document
text. IETF experience suggests that these roles typically
cannot all be handled by one person; four or five active
participants are typically required.
- 少なくとも数人が、必要な結果(例えば、プロトコル仕様)を生むための努力を費やしても構わないと思っていて、ワーキンググループの話題における十分な関心と専門的技術がありますか? ワーキンググループはかなりの努力を必要とします、ワーキンググループの過程の管理、ワーキンググループドキュメントの編集、および文書への貢献を含んでいて。 IETF経験は、通常、1人の人がこれらの役割をすべて扱うことができないのを示します。 4か5人の積極的な参加者が通常必要です。
- Does a base of interested consumers (end users) appear to
exist for the planned work? Consumer interest can be
measured by participation of end-users within the IETF
process, as well as by less direct means.
- 関心がある消費者(エンドユーザ)のベースは計画された仕事のために存在するように見えますか? IETFの過程の中のエンドユーザの参加、およびそれほどダイレクトでない手段で消費者関心を測定できます。
Considering the above criteria, the Area Director will decide whether to pursue the formation of the group through the chartering process.
上の評価基準を考えると、Areaディレクターは、特許の過程によるグループの構成を追求するかどうか決めるでしょう。
2.2. Charter
2.2. 憲章
The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director, although final approval is made by the IESG and all charters are reviewed by the Internet Architecture Board (IAB). A charter is a contract between a working group and the IETF to perform a set of tasks. A charter:
インターネット・アーキテクチャ委員会(IAB)によって見直された状態で、ワーキンググループの構成はIESGが最終承認をして、すべての特許がして、主として交渉されたa将来のワーキンググループが議長と関連Areaディレクターである特許を必要とします。 特許は1セットのタスクを実行するワーキンググループとIETFとの契約です。 特許:
1. Lists relevant administrative aspects of the working group;
1. ワーキンググループの関連管理局面を記載します。
2. Specifies the direction or objectives of the working group
and describes the approach that will be taken to achieve the
goals; and
2. ワーキンググループの指示か目的を指定して、目標を達成するために取られるアプローチについて説明します。 そして
3. Enumerates a set of milestones together with time frames for
their completion.
3. 彼らの完成のために時間枠と共に1セットの重大事件を列挙します。
When the prospective Chair, the Area Director and the IESG Secretary are satisfied with the charter form and content, it becomes the basis for forming a working group. The AD may require an initial draft of a charter to be available prior to holding an exploratory Birds of a Feather (BOF) meeting, as described below.
将来の議長、Areaディレクター、およびIESG長官が特許フォームと内容に満足しているとき、それはワーキンググループを形成する基礎になります。 Feather(BOF)ミーティングの踏査のBirdsを持つ前にADは、特許の初期の草稿が利用可能であることを必要とするかもしれません、以下で説明されるように。
Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group. Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering concrete "products".
憲章は、ワーキンググループの現在の状態、組織または目標を反映するために定期的に再交渉されるかもしれません。 したがって、特許はIETFとワーキンググループとの明白な重大事件を満たすために公約して、具体的な「製品」を渡している契約です。
Huizer & Crocker [Page 6] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[6ページ]RFC1603IETFワーキンググループガイドライン行進1994
Specifically, each charter consists of 6 sections:
明確に、各特許は6つのセクションから成ります:
Working group name
ワーキンググループ名
A working group name should be reasonably descriptive or
identifiable. Additionally, the group shall define an
acronym (maximum 8 printable ASCII characters) to reference
the group in the IETF directories, mailing lists, and
general documents.
ワーキンググループ名は、かなり描写的である、または身元保証可能であるべきです。 さらに、グループは頭文字語(8人の最大の印刷可能なASCII文字)をIETFディレクトリ、メーリングリスト、および一般のグループが記録する参照と定義するものとします。
Chair(s)
議長(s)
The working group may have one or two Chair(s) to perform
the administrative functions of the group. The email
address(es) of the Chair(s) shall be included.
ワーキンググループには、グループの行政機能を実行するために、1か2つの議長があるかもしれません。 議長のEメールアドレス(es)は含まれているものとします。
Area and Area Director(s)
領域と領域のディレクター(s)
The name of the IETF area with which the working group is
affiliated and the name and electronic mail address of the
associated Area Director.
関連Areaディレクターのワーキンググループが系列であるIETF領域の名前、名前、および電子メールアドレス。
Mailing list
メーリングリスト
It is required that an IETF working group have a general
Internet mailing list. Most of the work of an IETF working
group will be conducted that.
IETFワーキンググループには一般的なインターネットメーリングリストがあるのが必要です。 IETFワーキンググループの仕事の大部分が行われるでしょう。それ。
The charter shall include:
特許は以下を含んでいるものとします。
The address to which a participant sends a
subscription request and the procedures to follow when
subscribing,
関係者が購読要求を送るアドレスと申し込むとき従う手順
The address to which a participant sends submissions
and special procedures, if any, and
そして関係者がもしあれば差出と特別な手順を送るアドレス。
The location of the mailing list archive, if any.
もしあればメーリングリストアーカイブの位置
A message archive should be maintained in a public place
which can be accessed via FTP. The ability to retrieve from
the archive via electronic mail requests also is
recommended. Additionally, the address:
メッセージアーカイブはFTPでアクセスできる公共の場で維持されるべきです。 アーカイブから電子メール要求で検索する能力もお勧めです。 さらに、アドレス:
ietf-archive@cnri.reston.va.us
ietf-archive@cnri.reston.va.us
shall be included on the mailing list.
メーリングリストでは、含まれるでしょう。
Huizer & Crocker [Page 7] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[7ページ]RFC1603IETFワーキンググループガイドライン行進1994
NOTE: It is strongly suggested that the mailing list be on
a host directly connected to the IP Internet to facilitate
use of the SMTP expansion command (EXPN) and to allow mail
archive access via FTP, gopher and the like in keeping with
the general IETF rule for openness. If this is not possible,
the message archive and membership of the list must be made
available to those who request it by sending a message to
the list-request alias.
以下に注意してください。 SMTP拡大命令(EXPN)の使用を容易にして、風通しの良いように一般的なIETF規則で保つ際にFTP、リス、および同様のものでメールアーカイブアクセスを許すために直接IPインターネットに接続されたホストの上にメーリングリストがあることが強く提案されます。 これが可能でないなら、リスト要求別名にメッセージを送ることによってそれを要求する人はリストのメッセージアーカイブと会員資格を入手しなければなりません。
Description of working group
ワーキンググループの記述
The focus and intent of the group shall be set forth briefly. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph will frequently be used as an overview of the working group's effort.
グループの焦点と意図は簡潔に詳しく説明されるものとします。 単独でこのセクションを読むことによって、個人は、このグループがそれら自身の仕事に関連しているかどうか決めることができるべきです。 第一節はワーキンググループのために計画されていた問題領域、基礎、目標、およびアプローチ(es)の簡潔な概要をしなければなりません。 このパラグラフはワーキンググループの努力の概観として頻繁に使用されるでしょう。
The terms "they", "them" and "their" are used in this document as third-person singular pronouns.
そして、「それら」という用語、「それら」、「それら、」 本書では三人称単数代名詞として、使用されます。
To facilitate evaluation of the intended work and to provide
on-going guidance to the working group, the charter shall
describe the problem being solved and shall discuss
objectives and expected impact with respect to:
特許は、意図している仕事の評価を容易にして、継続している指導をワーキンググループに提供するために、解決されていることにおける問題について説明して、以下に関して目的と予想された衝撃について議論するものとします。
- Architecture
- Operations
- Security
- Network management
- Transition (where applicable)
- 構造--操作--セキュリティ--ネットワークマネージメント--変遷(適切であるところ)
Goals and milestones
目標と重大事件
The working group charter must establish a timetable for
work. While this may be re-negotiated over time, the list
of milestones and dates facilitates the Area Director's
tracking of working group progress and status, and it is
indispensable to potential participants identifying the
critical moments for input. Milestones shall consist of
deliverables that can be qualified as showing specific
achievement; e.g., "Internet-Draft finished" is fine, but
"discuss via email" is not. It is helpful to specify
milestones for every 3-6 months, so that progress can be
gauged easily. This milestone list is expected to be
updated periodically. Updated milestones are re-negotiated
with the Area Director and the IESG, as needed, and then are
submitted to the IESG Secretary:
ワーキンググループ特許は仕事のための時刻表を設立しなければなりません。 これは時間がたつにつれて再交渉されるかもしれませんが、重大事件と日付のリストはAreaディレクターのワーキンググループ進歩と状態の追跡を容易にします、そして、入力のために瀬戸際を特定する潜在的関係者にとって、それは不可欠です。 重大事件は特定の実績を示していながら資格を得られることができる提出物から成るものとします。 メールしてください。を通してしかし、例えば、「インターネット草稿は終わったこと」がすばらしい、「議論、」 ありません。 月の間、あらゆる3-6に重大事件を指定するのは、容易に進歩を測ることができるように役立っています。 この重大事件リストが定期的にアップデートすると予想されます。 アップデートされた重大事件を必要であるようにAreaディレクターとIESGに再交渉して、次に、IESG長官に提出します:
Huizer & Crocker [Page 8] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[8ページ]RFC1603IETFワーキンググループガイドライン行進1994
IESG-secretary@cnri.reston.va.us
IESG-secretary@cnri.reston.va.us
An example of a WG charter is in Appendix A.
WG特許に関する例がAppendix Aにあります。
2.3. Charter review & approval
2.3. 憲章レビューと承認
Working groups often comprise technically competent participants who are not familiar with the history of Internet architecture or IETF processes. This can, unfortunately, lead to good working group consensus about a bad design. To facilitate working group efforts, an Area Director may assign an Area Consultant from among the ranks of senior IETF participants. (Area Consultants are described in the section of Staff Roles.) At the discretion of the AD, approval of a new WG may be withheld in the absence of sufficient Consultant resources.
ワーキンググループはしばしばインターネット構造かIETFの過程の歴史に詳しくない技術的に有能な関係者を包括します。 残念ながら、これは悪いデザインに関する良いワーキンググループコンセンサスに通じることができます。 ワーキンググループの努力を容易にするために、Areaディレクターは年上のIETF関係者のランクからArea Consultantを割り当てるかもしれません。 (領域ConsultantsはStaff Rolesのセクションで説明されます。) ADの裁量では、十分なConsultantリソースがないとき新しいWGの承認は差し控えられるかもしれません。
Once the Area Director (and the Area Directorate, as the AD deems appropriate) has approved the working group charter, the charter is submitted for review by the IAB and approval by the Internet Engineering Steering Group using the criteria described previously.
そして、かつてのAreaディレクター、(ADが、適切であると考えるようなArea Directorate、承認されて、ワーキンググループ特許でありIABによるレビューのために特許を提出して、インターネットEngineering Steering Group使用による承認は以前に説明された評価基準を提出します。
The Internet Architecture Board (IAB) will review the charter of the proposed WG to determine the relationship of the proposed work to the overall architecture of the Internet Protocol Suite.
インターネット・アーキテクチャ委員会(IAB)は、インターネットプロトコルSuiteの総合的な構造に提案された仕事の関係を決定するために提案されたWGの特許を見直すでしょう。
The approved charter is submitted to the IESG Secretary who records and enters the information into the IETF tracking database and returns the charter in a form formatted by the database. The working group is announced to the IETF mailing list by the IESG Secretary.
承認された特許は、IETFの追跡データベースに情報を記録して、入力するIESG長官に提出して、データベースによってフォーマットされたフォームで特許を返します。 ワーキンググループはIESG長官によってIETFメーリングリストに発表されます。
2.4. Birds of a feather (BOF)
2.4. 同じ羽毛の鳥(転炉)
Often it is not clear whether an issue merits the formation of a working group. To facilitate exploration of the issues the IETF offers the possibility of a Birds of a Feather (BOF) session, as well as the early formation of an email list for preliminary discussion. Alternatively, a BOF may serve as a forum for a single presentation or discussion, without any intent to form a working group.
しばしば、問題がワーキンググループの構成に値するかどうかが、明確であるというわけではありません。 問題の探検を容易にするために、IETFはFeather(BOF)セッションのBirdsの可能性を提供します、予備的な討論のためのメールリストの早めの構成と同様に。 あるいはまた、BOFはただ一つのプレゼンテーションか議論のためのフォーラムとして機能するかもしれません、ワーキンググループを形成する少しも意図なしで。
A BOF is a session at an IETF meeting which permits "market research" and technical "brainstorming". Any individual may request permission to hold a BOF on a subject. The request must be filed with the relevant Area Director. The person who requests the BOF is usually appointed as Chair of the BOF. The Chair of the BOF is also responsible for providing a report on the outcome of the BOF.
BOFは「市場調査」を可能にするIETFミーティングと技術的な「ブレーンストーミング」でセッションです。 どんな個人も問題に関してBOFを持つ許可を要求するかもしれません。 関連Areaディレクターに要望書を提出しなければなりません。 通常、BOFを要求する人はBOFの議長に任命されます。 また、BOFの議長もBOFの結果に関するレポートを提供するのに責任があります。
Huizer & Crocker [Page 9] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[9ページ]RFC1603IETFワーキンググループガイドライン行進1994
The AD may require the conduct of email discussion, prior to authorizing a BOF. This permits initial exchanges and sharing of framework, vocabulary and approaches, in order to make the time spent in the BOF more productive. The AD may require that a BOF be held, prior to establishing a working group, and the AD may require that there be a draft of the WG charter prior to holding a BOF.
BOFを認可する前に、ADはメール議論の行為を必要とするかもしれません。 これは枠組み、ボキャブラリー、およびアプローチの初期の交換と共有を可能にします、BOFに費やされた時間をより生産的にするように。 ADは、ワーキンググループを設立する前にBOFが持たれているのを必要とするかもしれません、そして、ADはWGの草稿がBOFを持つ前の特許であったならそこでそれを必要とするかもしれません。
Usually the outcome of a BOF will be one of the following:
通常、BOFの結果は以下の1つになるでしょう:
- There was enough interest and focus in the subject to
warrant the formation of a WG;
- 対象には関心と焦点がWGの構成を保証するほどありました。
- The discussion came to a fruitful conclusion, with results
to be written down and published, however there is no need
to establish a WG; or
- 議論は書き留められて、発行されに結果と共に実り多い結論に来ました、どんな必要性もどんなにそこにWGを設立しないつもりであってもさえ。 または
- There was not enough interest in the subject to warrant the
formation of a WG.
- 対象へのWGの構成を保証できるくらいの関心がありませんでした。
There is an increasing demand for BOF sessions at IETF meetings. Therefore the following rules apply for BOFs:
BOFセッションを求める増えている需要がIETFミーティングにあります。 したがって、以下の規則はBOFsに申し込みます:
- All BOFs must have the approval of the appropriate Area
Director. The Secretariat will NOT schedule or allocate time
slots without the explicit approval of the Area Director.
- すべてのBOFsには、適切なAreaディレクターの承認がなければなりません。 事務局は、Areaディレクターの明白な承認なしで時間帯を計画もしませんし、割り当てもしないでしょう。
- The purpose of a BOF is to conduct a single, brief
discussion or to ascertain interest and establish goals for
a working group. All BOF organizers are required to submit a
brief written report of what transpired during the BOF
session together with a roster of attendees to the IESG
Secretary for inclusion in the Proceedings.
- BOFの目的は、単一の、そして、簡潔な議論を行うか、関心を確かめて、またはワーキンググループの目標を確立することです。 すべてのBOFオーガナイザーが、Proceedingsでの包含のためにBOFセッションの間に出席者の当直表と共に蒸散したことに関する簡潔な報告書をIESG長官に提出するのに必要です。
- A BOF may be held only once (ONE slot at one IETF Plenary
meeting).
- BOFは一度(1つのIETF PlenaryミーティングにおけるONEスロット)だけ持たれているかもしれません。
- Under unusual circumstances an Area Director may, at their
discretion, allow a BOF to meet for a second time. Typically
(though not a requirement) this is to develop a charter to
be submitted to the IESG.
- もう一度のAreaディレクターが彼らの裁量でBOFを会わせるかもしれない珍しい状況で。 これは、通常(もっとも、要件でない)、IESGに提出するために特許を開発するためのものです。
- BOFs are not permitted to meet three times.
- BOFsが3回会うことが許可されていません。
Huizer & Crocker [Page 10] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[10ページ]RFC1603IETFワーキンググループガイドライン行進1994
- A BOF may be held for single-event discussion, or may pursue
creation of normal IETF working groups for on-going
interactions and discussions. When the request for a BOF
comes from a formally-constituted group, rather than from an
individual, the rules governing the handling of the request
are the same as for all other BOFs and working groups.
- BOFは単一のイベント議論のために保持されるか、または継続している相互作用と議論のために正常なIETFワーキンググループの創設を追求するかもしれません。 BOFを求める要求が個人からというよりむしろ正式に構成されたグループから来るとき、要求の取り扱いを治める規則は他のすべてのBOFsとワーキンググループのように同じです。
- When necessary, WGs will be given priority for meeting space
over BOFs.
- 必要であるときに、WGsはBOFsの上で集会場が優先するでしょう。
3. WORKING GROUP OPERATION
3. ワーキンググループ操作
The IETF has basic requirements for open and fair participation and for thorough consideration of technical alternatives. Within those constraints, working groups are autonomous and each determines most of the details of its own operation with respect to session participation, reaching closure, etc. The core rule for operation is that acceptance or agreement is achieved via working group "rough consensus".
IETFには、開いていて公正な参加と技術的な代替手段の徹底的な考慮のための基本的な要件があります。 それらの規制の中では、ワーキンググループは自治です、そして、それぞれがセッション参加に関してそれ自身の操作の詳細の大部分を決定します、閉鎖などに達して 操作のためのコア規則は承認か協定がワーキンググループ「荒いコンセンサス」を通して達成されるということです。
A number of procedural questions and issues will arise over time, and it is the function of the Working Group Chair to manage the group process, keeping in mind that the overall purpose of the group is to make progress towards reaching rough consensus in realizing the working group's goals and objectives.
多くの手続き上の質問と問題が時間がたつにつれて起こるでしょう、そして、それはグループの過程を管理する作業部会議長の機能です、グループの総合的な目的がワーキンググループの目標と目的がわかる際に荒いコンセンサスに達することに向かって進展することであることを覚えておいて。
There are few hard and fast rules on organizing or conducting working group activities, but a set of guidelines and practices have evolved over time that have proven successful. These are listed here, with actual choices typically determined by the working group participants and the Chair.
ワーキンググループ活動を組織化するか、または行うとき、鉄則がわずかしかありませんが、成功したマニュアルと習慣は時間がたつにつれて、発展しました。 これらはここにワーキンググループの関係者と議長で通常決定している実際の選択で記載されています。
3.1. Session planning
3.1. セッション計画
For coordinated, structured WG interactions, the Chair must publish a draft agenda well in advance of the actual session. The agenda needs to contain at least:
連携していて、構造化されたWG相互作用に関しては、議長は実際のセッションのよく前に議題案を発表しなければなりません。 少なくとも含む議題の必要性:
- The items for discussion;
- 議論のための項目。
- The estimated time necessary per item; and
- 1項目あたり必要なおよそ時間。 そして
- A clear indication of what documents the participants will
need to read before the session in order to be well
prepared.
- 関係者を記録することの明確なしるしは、セッションの前によく準備されるために読む必要があるでしょう。
Huizer & Crocker [Page 11] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[11ページ]RFC1603IETFワーキンググループガイドライン行進1994
Publication shall include sending a copy to the working group mailing list and to the IETF-Announce list. Notices for the IETF-Announce list should be sent to:
公表は、ワーキンググループメーリングリストと、そして、IETF発表しているリストにコピーを送るのを含んでいるものとします。 以下のことのためにIETF発表しているリストのための通知を送るべきです。
ietf-announce-post@cnri.reston.va.us
ietf-announce-post@cnri.reston.va.us
All working group actions shall be taken in a public forum, and wide participation is encouraged. A working group will conduct much of its business via electronic mail distribution lists but may meet periodically to discuss and review task status and progress, to resolve specific issues and to direct future activities. It is common, but not required, that a working group will meet at the trimester IETF Plenary events. Additionally, interim sessions may be scheduled for telephone conference, video teleconference, or for face-to-face (physical) sessions.
公共のフォーラムですべてのワーキンググループ行動を取るものとします、そして、広い参加を奨励します。 ワーキンググループは、電子メール発送先リストでビジネスの多くを行いますが、タスク状態と進歩について議論して、調査して、特定の問題を解決して、今後の活動を指示するために定期的に集まるかもしれません。 それは、一般的ですが、必要でなく、ワーキンググループは三ヵ月間IETF Plenary出来事で会合するでしょう。 さらに、当座のセッションは電話会議、ビデオ電子会議か面と向かっている(物理的な)セッションのために予定されるかもしれません。
All working group sessions (including those held outside of the IETF meetings) shall be reported by making minutes available. These minutes should include the agenda for the session, an account of the discussion including any decisions made, and a list of attendees. The Working Group Chair is responsible for insuring that session minutes are written and distributed, though the actual task may be performed by someone designated by the Working Group Chair. The minutes shall be submitted in printable ASCII text for publication in the IETF Proceedings, and for posting in the IETF Directories and are to be sent to:
すべてのワーキンググループセッション(IETFミーティングの外に保持されたものを含んでいる)が、数分を利用可能にすることによって、報告されるものとします。 これらの数分はセッションのための議題、どんな決定も作った議論包含のアカウント、および出席者のリストを含むべきです。 セッション議事録が書かれていて、分配されるのを保障するのに作業部会議長は責任があります、実際のタスクが作業部会議長によって任命されただれかによって実行されるかもしれませんが。 議事録は、IETF Proceedingsでの公表、およびIETFディレクトリにおける任命のために印刷可能なASCIIテキストで提出して、以下のことのために送ることでしょう。
minutes@cnri.reston.va.us
minutes@cnri.reston.va.us
3.2. Session venue
3.2. セッション開催地
Each working group will determine the balance of email and face-to- face sessions that is appropriate for achieving its milestones. Electronic mail permits the widest participation; face-to-face meetings often permit better focus and therefore can be more efficient for reaching a consensus among a core of the working group participants. In determining the balance, the WG must ensure that its process does not serve to exclude contribution by email-only participants. Also note that decisions reached during IETF meetings are NOT final, but must be conveyed to the mailing list to verify WG consensus.
各ワーキンググループはメールと表面から表面へのセッションの重大事件を達成するのに、適切なバランスを決定するでしょう。 電子メールは最も広い参加を可能にします。 さしの会談は、しばしばより良い焦点を可能にして、ワーキンググループの関係者のコアの中でコンセンサスに達するには、したがって、より効率的である場合があります。 バランスを決定する際に、WGは、過程が、メールだけ関係者による貢献を除くのに役立たないのを確実にしなければなりません。 また、IETFミーティングの間に達した決定を最終的ではありませんが、メーリングリストに伝えなければならないことに注意して、WGコンセンサスについて確かめてください。
IETF Meetings
IETFミーティング
If a WG needs a session at an IETF meeting, the Chair must apply for time-slots as soon as the first announcement of that IETF meeting is made by the IETF Secretariat to the WG-chairs list. Session time is a scarce resource at IETF meetings, so placing requests early will
WGがIETFミーティングでセッションを必要とするなら、そのIETFミーティングの最初の発表がIETF事務局によってWG-いすリストにされるとすぐに、議長は時間帯に申し込まなければなりません。 セッション時間がIETFミーティングで不十分なリソースである、したがって、早く要求を置くのはそうするでしょう。
Huizer & Crocker [Page 12] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[12ページ]RFC1603IETFワーキンググループガイドライン行進1994
facilitate schedule coordination for WGs requiring the same set of experts.
同じセットに専門家を要求するWGsのためにスケジュールコーディネートを容易にしてください。
The application for a WG session at an IETF meeting shall be made to the IETF Secretariat. Alternatively some Area Directors may want to coordinate WG sessions in their area and request that time slots be coordinated through them. After receiving all requests for time slots by WGs in the area, the Area Director(s) form a draft session- agenda for their area, which is then sent to the WG chairs of the area. After approval it will be sent to the IETF Secretariat.
IETFミーティングにおけるWGセッションのためのアプリケーションをIETF事務局にするものとします。 代わりに何人かのAreaディレクターが、それらの領域でWGセッションを調整して、時間帯がそれらを通して調整されるよう要求したがっているかもしれません。 その領域にWGsで時間帯を求めるすべての要求を受け取った後に、Areaディレクターはa草稿セッション議題を彼らの領域に形成します。(次に、それは、領域のWGいすに送られます)。 承認の後に、IETF事務局にそれを送るでしょう。
An application must contain:
アプリケーションは以下を含まなければなりません。
- The amount of time requested;
- 要求された時間。
- The rough outline of the WG agenda that is expected to be
covered;
- 覆われていると予想されるWG議題の概要。
- The estimated number of people that will attend the WG
session;
- WGセッションに出席する人々の概算数。
- Related WGs that must not be scheduled for the same time
slot(s); and
- 同じ時間帯のために予定してはいけないWGsは関係づけました。 そして
- Individuals whose attendance is desired.
- 出席が望まれている個人。
The Secretariat allots time slots on the basis of the session-agenda made by the Area Director(s). If the proposed session- agenda for an area does not fit into the IETF meeting-agenda, the IETF Secretariat will adjust it to fit, after consulting the Area Director(s) and the relevant chairs. The Secretariat will then form a draft session- agenda and distribute it among the Working Group Chairs for final approval.
事務局はAreaディレクターによって作られたセッション議題に基づいて時間帯を割り当てます。 領域のための提案されたセッション議題がIETF会議の議題に収まらないと、IETF事務局は、Areaに相談した後にディレクターと関連いすに合うようにそれを調整するでしょう。 事務局は、次に、a草稿セッション議題を形成して、最終承認のために作業部会Chairsにそれを分配するでしょう。
NOTE: While open discussion and contribution is essential to working group success, the Chair is responsible for ensuring forward progress. When acceptable to the WG, the Chair may call for restricted participation (but not restricted attendance!) at IETF working group sessions for the purpose of achieving progress. The Working Group Chair then has the authority to refuse to grant the floor to any individual who is unprepared or otherwise covering inappropriate material.
以下に注意してください。 公開討論と貢献はワーキンググループ成功に不可欠ですが、議長は前進の進歩を確実にするのに責任があります。 進歩を遂げる目的のためのIETFワーキンググループセッションのときにWGに許容できるとき、議長は制限された参加(しかし、制限された出席でない!)を求めるかもしれません。 そして、作業部会議長には、どんな用意ができていていない個人かそうでなければ、不適切な素材をカバーするのにも床を与えるのを拒否する権威があります。
On-line
オンライン
It can be quite useful to conduct email exchanges in the same manner as a face-to-face session, with published schedule and agenda, as well as on-going summarization and consensus polling.
面と向かっているセッションと同じ方法でメール交換を行うのはかなり役に立つ場合があります、発行されたスケジュールと議題で、継続している総括とコンセンサス世論調査と同様に。
Huizer & Crocker [Page 13] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[13ページ]RFC1603IETFワーキンググループガイドライン行進1994
Many working group participants hold that mailing list discussion is the best place to consider and resolve issues and make decisions. Choice of operational style is made by the working group itself. It is important to note, however, that Internet email discussion is possible for a much wider base of interested persons than is attendance at IETF meetings, due to the time and expense required to attend.
多くのワーキンググループの関係者が、メーリングリスト議論が考えて、問題を解決して、決定をする最も良い場所であることを保持します。 操作上のスタイルの選択はワーキンググループ自体によってされます。 しかしながら、関心がある人々のはるかに広いベースに、インターネットメール議論がIETFミーティングにおける出席より可能であることに注意するのは重要です、出席するのに必要である時間と費用のため。
3.3. Session management
3.3. セッション管理
Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by balloting, humming, or any other means on which the WG agrees (by rough consensus, of course).
ワーキンググループは「荒いコンセンサス」の過程で決定をします。 IETFコンセンサスは、これがもちろん好まれますが、すべての関係者が同意するのを必要としません。 一般に、ワーキンググループの優位な眺めは広がっているものとします。 (しかしながら、「支配」がボリュームかしかし、固執、むしろ協定の、より一般的な意味に基づいて断固としないことであることに注意しなければなりません。) コンセンサスは投票、鼻歌、またはWGが同意する(もちろん荒いコンセンサスで)いかなる他の手段でも決定できます。
The challenge to managing working group sessions is to balance the need for open and fair consideration of the issues against the need to make forward progress. The working group, as a whole, has the final responsibility for striking this balance. The Chair has the responsibility for overseeing the process but may delegate direct process management to a formally-designated Facilitator.
ワーキンググループセッションを管理することへの挑戦は必要性に対する問題の開いていて公正な考慮が前進の進歩をする必要性のバランスをとることです。 ワーキンググループには、このバランスをとることへの最終責任が全体であります。 議長は、過程を監督するために責任を持っていますが、正式に指定されたFacilitatorへ直接法管理を代表として派遣するかもしれません。
It is occasionally appropriate to revisit a topic, to re-evaluate alternatives or to improve the group's understanding of a relevant decision. However, unnecessary repeated discussions on issues can be avoided if the Chair makes sure that the main arguments in the discussion (and the outcome) are summarized and archived after a discussion has come to conclusion. It is also good practice to note important decisions/consensus reached by email in the minutes of the next 'live' session, and to summarize briefly the decision-making history in the final documents the WG produces.
話題を再訪させるか、代替手段を再評価するか、またはグループの関連決定の理解を改良するのが時折適切です。 しかしながら、議長が、議論が結論に来た後に、議論(そして、結果)における主な議論がまとめられて、格納されるのを確実にするなら、問題についての不要な繰り返された議論を避けることができます。 また、メールで重要な決定/コンセンサスに次の'ライブな'セッションの議事録の間達したことに注意して、簡潔にWGが生産する最終合意文書における意志決定歴史をまとめるのは、良い習慣です。
To facilitate making forward progress, a Working Group Chair may wish to direct a discussion to reject or defer the input from a member, based upon the following criteria:
前進の進歩をするのを容易にするために、作業部会議長は、メンバーからの入力を拒絶するか、または延期するよう議論に指示したがっているかもしれません、以下の評価基準に基づきます:
Old
古い
The input pertains to a topic that already has been resolved
and is redundant with information previously available;
入力は既に決議された、情報が以前に利用可能な状態で余分な話題に関係します。
Huizer & Crocker [Page 14] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[14ページ]RFC1603IETFワーキンググループガイドライン行進1994
Minor
未成年者
The input is new and pertains to a topic that has already
been resolved, but it is felt to be of minor import to the
existing decision;
入力は、新しく、既に決議された話題に関係しますが、既存の決定には小さい方の輸入があるのは、感じられます。
Timing
タイミング
The input pertains to a topic that the working group has not
yet opened for discussion; or
入力はワーキンググループが議論のためにまだ開いていない話題に関係します。 または
Scope
範囲
The input is outside of the scope of the working group
charter.
入力がワーキンググループ特許の範囲の外にあります。
3.4. Contention and appeals overview
3.4. 主張と上告概観
In the course of group design processes, strife happens. Strife and contention are particularly likely when working groups comprise many constituencies. On the other hand differences in view are vital to the success of the IETF and healthy debate is encouraged. Sometimes debates degenerate into something akin to warfare. For these circumstances, the IETF has an extensive review and appeals process.
グループデザイン過程の間に、不和は起こります。 ワーキンググループが多くの選挙民を包括するとき、不和と主張は特にありそうです。 他方では、視点の違いがIETFの成功に必要です、そして、健康な討論は奨励されます。 時々、討論は戦争と何か同系であるものに陥ります。 これらの事情に関しては、IETFには、大量のレビューと上告の過程があります。
Formal procedures for requesting review and conducting appeals are documented in The Internet Standards Process [1]. A brief summary is provided, here.
レビューを要求して、上告を行うための正式手順はインターネットStandards Process[1]に記録されます。 簡潔な概要をここに提供します。
In fact the IETF approach to reviews and appeals is quite simple: When an IETF participant feels that matters have not been conducted properly, they should state their concern to a member of IETF management. In other words, the process relies upon those who have concerns raising them. If the result is not satisfactory, there are several levels of appeal available, to ensure that review is possible by a number of people uninvolved in the matter in question.
事実上、レビューと上告へのIETFアプローチはかなり簡単です: IETF関係者が、物質が適切に行われていないと感じると、彼らはIETF管理のメンバーへの自分達の関心を述べるべきです。 言い換えれば、過程はそれらを上げる関心を持っている人を当てにします。 結果が満足できないなら、レビューが係争中の問題で無関心な多くの人々が可能であることを保証するために、利用可能な上告のいくつかのレベルがあります。
Reviews and appeals step through four levels, each in turn:
レビューと上告は4つのレベルを通してそれぞれ順番に踏まれます:
WG Chair
WG議長
An appeal must begin with the management closest to the
operation of the working group, even if the concern applies
to their own handling of working group process.
管理がワーキンググループの操作の最も近くにある状態で、上告は始まらなければなりません、関心がそれら自身のワーキンググループの過程の取り扱いに適用されても。
Huizer & Crocker [Page 15] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[15ページ]RFC1603IETFワーキンググループガイドライン行進1994
Area
領域
If discussion and review with the WG Chair do not produce a
satisfactory result, the complainant may bring their concern
to the cognizant Area Director.
WG議長との議論とレビューが満足できる結果を生まないなら、原告は認識力があるAreaディレクターに彼らの関心をもたらすかもしれません。
IESG
IESG
If a concerned party is not satisfied with the results of
the area-level review, then they may bring the matter to the
IESG Chair and the Area Director for Standards & Processes.
The IESG Chair and the Standards & Processes AD will bring
the issue before the full IESG for an additional review and
will report the resolution back to the parties.
関係者が領域レベルレビューの結果に満たされていないなら、それらはStandards&ProcessesにIESG議長とAreaディレクターにその件をもたらすかもしれません。 IESG議長とStandards&Processes ADは追加レビューに完全なIESGの前で問題をもたらして、パーティーに解決の報告を持ちかえるでしょう。
IAB
IAB
The IAB provides a final opportunity to appeal the results
of previous reviews. If a concerned party does not accept
the outcome of the IESG review, then they may take their
concern to the IAB, by contacting the IAB Chair.
IABは前のレビューの結果を上告する最終的な機会を提供します。 関係者がIESGレビューの結果を受け入れないなら、彼らは自分達の関心をIABに取るかもしれません、IAB議長に連絡することによって。
Concerns entail either a disagreement with technical decisions by the working group or with the process by which working group business has been conducted. Technical disagreements may be about specific details or about basic approach. When an issue pertains to preference, it should be resolved within the working group. When a matter pertains to the technical adequacy of a decision, review is encouraged whenever the perceived deficiency is noted. For matters having to do with preference, working group rough consensus will dominate.
関心はワーキンググループによる技術的判断かワーキンググループ業務が行われた過程との不一致を伴います。 技術的な不一致は特定の詳細か基本的なアプローチに関するものであるかもしれません。 問題が好みに関するとき、それはワーキンググループの中で決議されるべきです。 件が決定の技術的な妥当性に関するとき、知覚された欠乏が注意されるときはいつも、レビューは奨励されます。 好みと関係がある件のために、ワーキンググループの荒いコンセンサスは抑えられるでしょう。
When a matter pertains to working group process, it is important that those with a concern be clear about the manner in which the process was not open or fair and that they be willing to discuss the issue openly and directly. In turn, the IETF management will make every effort to understand how the process was conducted, what deficiencies were present (if any) and how the matter should be corrected. The IETF functions on the good will and mutual respect of its participants; continued success requires continued attention to working group process.
件がワーキンググループの過程に関するとき、関心を伴うそれらが過程が開かないで、また公正でなかった方法に関して明確であり、彼らが、オープンに直接問題に取り組んでも構わないと思っているのは、重要です。 順番に、IETF経営者側は過程がどのように行われたか、そして、どんな欠乏が存在していたか、そして、(もしあれば)その件がどのように修正されるべきであるかを理解するためのあらゆる努力をするでしょう。 IETFは関係者の好意と相互尊重で機能します。 継続的な成功はワーキンググループの過程に関する継続的な注意を必要とします。
4. WORKING GROUP TERMINATION
4. ワーキンググループ終了
Working groups are typically chartered to accomplish a specific task. After that task is complete, the group will be disbanded. However if a WG produces a Proposed or Draft Standard, the WG will become dormant rather than disband (i.e., the WG will no longer conduct
ワーキンググループは、特定のタスクを達成するために通常チャーターされます。 そのタスクが完全になった後に、グループは解散されるでしょう。 しかしながら、WGがProposedかDraft Standardを生産するなら、WGが解散するよりむしろ眠るようになる、(すなわち、WGはもう伝導しないでしょう。
Huizer & Crocker [Page 16] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[16ページ]RFC1603IETFワーキンググループガイドライン行進1994
formal activities, but the mailing list will remain available to review the work as it moves to Draft Standard and Standard status.)
ホルマール活性、メーリングリストだけがDraft StandardとStandard状態に動くとき仕事を見直すために利用可能なままで残るでしょう。)
If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, the group, in consultation with its Area Director can either:
グループ、ワーキンググループが特許に概説された仕事を終了できないのが何らかのポイントで明白になるなら、Areaとの相談では、ディレクターはなることができます:
1. Recharter to refocus on a smaller task,
1. より小さいタスクに焦点を再び合わせる再認可
2. Choose new Chair(s), or
2. または新しい議長を選んでください。
3. Disband.
3. 解散してください。
If the working group disagrees with the Area Director's choice, it may appeal to the IESG.
ワーキンググループがAreaディレクターの選択と意見を異にするなら、それはIESGの好みに合うかもしれません。
5. STAFF ROLES
5. スタッフの役割
Working groups require considerable care and feeding. In addition to general participation, successful working groups benefit from the efforts of participants filling specific functional roles.
ワーキンググループはかなりの注意と食べることを必要とします。 一般的な参加に加えて、うまくいっているワーキンググループは特定の機能的役割をいっぱいにしている関係者の努力の利益を得ます。
5.1. WG Chair
5.1. WG議長
The Working Group Chair is concerned with making forward progress through a fair and open process, and has wide discretion in the conduct of WG business. The Chair must ensure that a number of tasks are performed, either directly or by others assigned to the tasks. This encompasses at the very least the following:
作業部会議長は、公正で開いている過程で前進の進歩をするのに関係があって、WGビジネスの行為で広い思慮深さを持っています。 議長は、多くのタスクが直接かタスクに選任された他のものによって実行されるのを保証しなければなりません。 これは少なくとも以下を取り囲みます:
Ensure WG process and content management
WGの過程とコンテンツ管理を確実にしてください。
The Chair has ultimate responsibility for ensuring that a
working group achieves forward progress and meets its
milestones. For some working groups, this can be
accomplished by having the Chair perform all management-
related activities. In other working groups -- particularly
those with large or divisive participation -- it is helpful
to allocate process and/or secretarial functions to other
participants. Process management pertains strictly to the
style of working group interaction and not to its content.
It ensures fairness and detects redundancy. The secretarial
function encompasses document editing. It is quite common
for a working group to assign the task of specification
Editor to one or two participants. Often, they also are
part of the design team, described below.
議長には、ワーキンググループが前進の進歩を遂げて、重大事件を満たすのを確実にすることへの最終責任があります。 いくつかのワーキンググループに関しては、議長にすべての管理関連活動を実行させることによって、これを達成できます。 他のワーキンググループ(特に大きいか分析的な参加があるそれら)では、過程、そして/または、業務代理機能を他の関係者に割り当てるのは役立っています。 工程管理は厳密に内容ではなく、ワーキンググループ相互作用のスタイルに関係します。 それは、公正を確実にして、冗長を検出します。 業務代理機能はドキュメント編集を成就します。 ワーキンググループが仕様Editorに関するタスクを1か2人の関係者に割り当てるのは、全く一般的です。 また、しばしば、それらは以下で説明されたデザインチームの一部です。
Huizer & Crocker [Page 17] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[17ページ]RFC1603IETFワーキンググループガイドライン行進1994
Moderate the WG email list
WGメールリストを加減してください。
The Chair should attempt to ensure that the discussions on
this list are relevant and that they converge to consensus
agreements. The Chair should make sure that discussions on
the list are summarized and that the outcome is well
documented (to avoid repetition). The Chair also may choose
to schedule organized on-line "sessions" with agenda and
deliverables. These are structured as true meetings,
conducted over the course of several days (to allow
participation across the Internet.) Participants are
expected to allocate time to the meeting, usually in the
range of 1-2 hours per day of the "meeting".
議長は、このリストにおける議論が関連していて、それらがコンセンサス協定に一点に集まるのを保証するのを試みるべきです。 議長は、リストにおける議論がまとめられて、結果がよく記録されるのを(反復を避ける)確実にするべきです。 議長も、議題と提出物との組織化されたオンライン「セッション」の計画をするのを選ぶかもしれません。 これらは数日(インターネットの向こう側に参加を許す)の過程にわたって行われた本当のミーティングとして構造化されます。 関係者が時間をミーティングに割り当てると予想されます、通常「ミーティング」の日あたりの1〜2時間の範囲で。
Organize, prepare and chair face-to-face & on-line formal sessions
面と向かっていてオンラインの正式なセッションを計画して、準備して、議長を務めてください。
The Chair should plan and announce sessions well in advance.
(See section on Session Planning for exact procedures.)
議長は、よくセッションで早く計画して、発表するべきです。 (正確な手順に関してSession Planningの上のセクションを見てください。)
Communicate results of sessions
セッションの結果を伝えてください。
The Chair and/or Secretary must ensure that minutes of a
session are taken and that an attendance list is circulated.
See the section on Session Documents for detailed
procedures.
議長、そして/または、長官は、セッションの議事録がかかって、出席リストが循環するのを保証しなければなりません。 詳細手順書に関してSession Documentsの上のセクションを見てください。
Immediately after a session, the WG Chair must immediately
provide the Area Director with a very short report
(approximately one paragraph, via email) on the session.
This is used in an Area Report as presented in the
Proceedings of each IETF meeting.
セッション直後、WG議長はすぐに、セッションに関する非常に短いレポート(メールを通したおよそ1つのパラグラフ)をAreaディレクターに提供しなければなりません。 これはそれぞれのIETFミーティングのProceedingsに提示されるようにArea Reportで使用されます。
Distribute the work
仕事を広げてください。
Of course each WG will have participants who may not be able
(or want) to do any work at all. Most of the time the bulk
of the work is done by a few dedicated participants. It is
the task of the Chair to motivate enough experts to allow
for a fair distribution of the workload.
もちろん各WGには、全くどんな仕事もするために、できないかもしれない関係者(または、欲しいです)がいるでしょう。 たいてい、仕事の大半が数人のひたむきな関係者によって行われます。 それはワークロードの公正な分配を考慮できるくらいの専門家を動機づける議長に関するタスクです。
Document development
ドキュメント開発
Working groups produce documents and documents need authors.
The Chair will make sure that authors of WG documents
incorporate changes as discussed by the WG. See the section
on Session Documents for details procedures.
ワーキンググループは書類を提示します、そして、ドキュメントは作者を必要とします。 議長は、WGによって議論されているようにWGドキュメントの作者が変化を取り入れるのを確実にするでしょう。 詳細手順に関してSession Documentsの上のセクションを見てください。
Huizer & Crocker [Page 18] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[18ページ]RFC1603IETFワーキンググループガイドライン行進1994
Document publication
ドキュメント公表
The Chair and/or Secretary will work with the RFC Editor to
ensure document conformance with RFC publication
requirements and to coordinate any editorial changes
suggested by the RFC Editor. A particular concern is that
all participants are working from the same version of a
document at the same time.
議長、そして/または、長官は、RFC公表要件でドキュメント順応を確実にして、RFC Editorによって勧められたどんな編集の変化も調整するためにRFC Editorと共に働くでしょう。 特別の関心はすべての関係者が同時にドキュメントの同じバージョンから働いているということです。
5.2. WG Editor/Secretary
5.2. WGエディタ/長官
Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Editor's job is to record WG decisions, rather than to perform basic specification.
何分もかかって、ワーキンググループドキュメントを編集するのはしばしば明確に指定された関係者かセットの関係者によって実行されます。 この役割に、Editorの仕事は基本の仕様を実行するというよりむしろWG決定を記録することです。
5.3. WG Facilitator
5.3. WGまとめ役
When meetings tend to become distracted or divisive, it often is helpful to assign the task of "process management" to one participant. Their job is to oversee the nature, rather than the content, of participant interactions. That is, they attend to the style of the discussion and to the schedule of the agenda, rather than making direct technical contributions themselves.
ミーティングが、そらされるか分析的になる傾向があるとき、「工程管理」に関するタスクを1人の関係者に割り当てるのはしばしば役立っています。 彼らの仕事は関与している相互作用の内容よりむしろ自然を監督することです。 すなわち、彼らはダイレクト技術的な貢献自体をするよりむしろ議論のスタイルと、そして、議題のスケジュールに出席します。
5.4. Design teams
5.4. デザインチーム
The majority of the detailed specification effort within a working group may be done by self-selecting sub-groups, called design teams, with the (implicit or explicit) approval of the working group. The team may hold closed sessions for conducting portions of the specification effort. In some cases design teams are necessary to make forward progress when preparing a document. All work conducted by a design team must be available for review by all working group participants and the design team must be responsive to the direction of the working group's consensus.
デザインチームは、自己にサブグループを選択することによってワーキンググループの中の仕様詳細の努力の大部分をするかもしれないと呼びました、ワーキンググループの(暗黙か明白)の承認をもって。 チームは仕様の努力の部分を行うための非公開審議を保持するかもしれません。 いくつかの場合、デザインチームが、書類を作成するとき、前進の進歩をするのに必要です。 デザインチームによって行われたすべての仕事がすべてのワーキンググループの関係者によるレビューに利用可能であるに違いありません、そして、デザインチームはワーキンググループのコンセンサスの方向に敏感であるに違いありません。
5.5. Area Consultant
5.5. 領域のコンサルタント
At the discretion of the AD, a Consultant may be assigned to a working group. Consultants are senior participants in the IETF community. They have technical background appropriate to the WG and experience in Internet architecture and IETF process.
ADの裁量では、Consultantはワーキンググループに配属されるかもしれません。 コンサルタントはIETF共同体の年上の関係者です。 彼らで、技術的なバックグラウンドはインターネット構造とIETFの過程のWGと経験に適切になります。
Huizer & Crocker [Page 19] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[19ページ]RFC1603IETFワーキンググループガイドライン行進1994
5.6. Area Director
5.6. 領域のディレクター
Area Directors are responsible for ensuring that working groups in their area produce coherent, coordinated, architecturally consistent and timely output as a contribution to the overall results of the IETF. This very general description encompasses at the very least these detailed tasks related to working groups:
それらの領域のワーキンググループがIETFの総合的な結果への貢献として一貫性を持っていて、連携していて、建築上一貫してタイムリーな出力を起こすのを確実にするのに領域のディレクターは責任があります。 この非常に一般的な記述はワーキンググループに関連するこれらの詳細なタスクを少なくとも包含します:
Area planning
領域計画
The Area Director determines activities appropriate to the
area. This may include initiating working groups directly,
rather than waiting for proposals from IETF participants.
Areaディレクターはその領域に適切な活動を決定します。 これは、IETF関係者から提案を待っているより直接むしろワーキンググループを開始するのを含むかもしれません。
Coordination of WGs
WGsのコーディネート
The Area Director coordinates the work done by the various
WGs within (and sometimes even outside) the relevant area.
Areaディレクターは(時々外さえ)関連領域の中の様々なWGsによって行われた仕事を調整します。
IETF Meeting Schedule
IETFミーティングスケジュール
The Director tries to coordinate sessions in such a way that
experts can attend the relevant sessions with a minimum of
overlap and gaps between sessions. (See section on WG
sessions for details.)
ディレクターは専門家が最小オーバラップとの関連セッションに出席できるような方法におけるセッションとセッションのギャップを調整しようとします。 (詳細のためのWGセッションにセクションを見てください。)
Reporting
報告します。
The Area Director reports to the IETF on progress in the
area.
Areaディレクターはその領域での進歩のIETFに報告します。
Reviewing
論評します。
The Area Director may appoint independent reviewers prior to
document approval. The Area Director tracks the progress of
documents from the area through the IESG review process, and
report back on this to the WG Chair(s).
Areaディレクターはドキュメント承認の前に独立している評論家を任命するかもしれません。 AreaディレクターはこれでIESG吟味の過程、および領域からレポートでのドキュメントの進歩をWG議長に追跡します。
Progress tracking
進歩追跡
The Area Director tracks and manages the progress of the
various WGs with the aid of a regular status report on
documents and milestones that is generated by the IESG
Secretary. The Area Director forwards this report to the WG
chairs. This in turn helps the chairs to manage their WGs.
Areaディレクターは、ドキュメントと重大事件における通常の現状報告の援助がIESG長官によって発生している様々なWGsの進歩を追跡して、管理します。 AreaディレクターはこのレポートをWGいすに転送します。 これは、いすが彼らのWGsを管理するのを順番に助けます。
Huizer & Crocker [Page 20] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[20ページ]RFC1603IETFワーキンググループガイドライン行進1994
5.7. Area Directorate
5.7. 領域の管理職
An area directorate consists of senior members of the technical community and are appointed by the Area Director who then tasks them with technical oversight and review of specific area activities. An Area Director chairs the directorate. At the request of the AD, directorate members conduct specification reviews and may be assigned as Area Consultants, to provide architectural assistance.
領域の管理職は、技術的な共同体のシニアメンバーから成って、次に特定の領域活動の技術的な見落としとレビューで彼らに仕事を課すAreaディレクターによって任命されます。 Areaディレクターは管理職をまとめます。 ADの依頼で、管理職のメンバーは、建築支援を提供するために仕様レビューを行って、Area Consultantsとして選任されるかもしれません。
6. WORKING GROUP DOCUMENTS
6. ワーキンググループドキュメント
6.1. Session documents
6.1. セッションドキュメント
All relevant documents for a session (including the final agenda) should be published and available at least two weeks before a session starts.
セッションが始まる少なくとも2週間前に、セッション(最終的な議題を含んでいる)のためのすべての関連ドキュメントが、発行されていて利用可能であるべきです。
It is strongly suggested that the WG Chair make sure that an anonymous FTP directory be available for the upcoming session. All relevant documents (including the final agenda and the minutes of the last session) should be placed in this directory. This has the advantage that all participants can FTP all files in this directory and thus make sure they have all relevant documents. Also, it will be helpful to provide electronic mail-based retrieval for those documents.
WG議長が、公開FTPディレクトリが今度のセッションに利用可能であることを確実にすることが強く提案されます。 すべての関連ドキュメント(最終的な議題と納会の議事録を含んでいる)がこのディレクトリに置かれるべきです。 これには、彼らにすべての関連ドキュメントがあるのを確信していた状態で、すべての関係者缶のFTPがこのディレクトリとその結果、造ですべてファイルする利点があります。 また、それらのドキュメントのための電子メールベースの検索を提供するのも役立つでしょう。
6.2. IETF meeting document archive
6.2. IETFミーティングドキュメントアーカイブ
In preparing for an IETF meeting it is helpful to have ready access to all documents that are being reviewed. While documents usually are placed in the internet-drafts Internet Repository or in the respective working group archives or just published in some mail- lists, there are just too many things to browse or read through. Also, many documents are modified immediately before a meeting.
IETFミーティングの用意をする際に、再検討されているすべてのドキュメントに持ち合わせのアクセスを持っているのは役立っています。 ドキュメントは、通常インターネット草稿インターネットRepositoryかそれぞれのワーキンググループアーカイブに置かれるか、またはいくつかのメールリストでただ発表されますが、ブラウズするか、または読み通すちょうどあまりに多くのものがあります。 また、多くのドキュメントがミーティングの直前変更されます。
The InterNIC Directory and Database Services provides a current- ietf-docs archive to enable people to get all documents that are relevant for the up-coming IETF meeting. This document database will be removed two weeks after the IETF meeting.
InterNICディレクトリとDatabase Servicesは、人々がすべての上がっている来るIETFミーティングにおいて、関連しているドキュメントを手に入れるのを可能にするために現在のietf-docsアーカイブを提供します。 IETFミーティングの2週間後にこの文書データベースを取り除くでしょう。
The completeness of this archive depends on the authors and working group chairs submitting the documents. Each WG Chair is requested to submit the agenda to this archive.
このアーカイブの完全性は書類を提出する作者とワーキンググループいすに頼っています。 それぞれのWG議長がこのアーカイブに議題を提出するよう要求されています。
Structure of the archive:
アーカイブの構造:
On ds.internic.net documents will be stored under the appropriate working group name under the appropriate area name in the directory:
ds.internic.netに、ドキュメントはディレクトリに適切な領域名の下で適切なワーキンググループ名の下で格納されるでしょう:
Huizer & Crocker [Page 21] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[21ページ]RFC1603IETFワーキンググループガイドライン行進1994
/pub/current-ietf-docs
/pub/current-ietf-docs
Each area will also have a directory called bof where a document to be discussed in a BOF meeting will be placed. At the area level a directory called plenary will be created to hold documents or presentation material related to a plenary session. Any filename conflicts will be resolved by the InterNIC's administrator and the submitter will be informed via electronic mail. Example:
また、各領域には、BOFミーティングで議論されるべきドキュメントが置かれる転炉と呼ばれるディレクトリがあるでしょう。 領域レベルでは、絶対的であると呼ばれるディレクトリは、ドキュメントかプレゼンテーションの材料が本会議に関連するままにするために作成されるでしょう。 どんなファイル名闘争もInterNICの管理者によって解決されるでしょう、そして、submitterは電子メールを通して知識があるようになるでしょう。 例:
/pub/current-ietf-docs/app/osids
/pub/current-ietf-docs/int/sip
現在の/pub/current-ietf-docs/装置/osids/パブ/ietf-docs/int/一口
Access via anonymous FTP:
公開FTPを通したアクセス:
Anonymous FTP to ds.internic.net and change directory to
ds.internic.netと変化ディレクトリへのアノニマス・エフテーピー
/pub/current-ietf-docs/
/pub/current-ietf-docs/
and browse and get the document of interest.
そして、興味深いドキュメントをブラウズして、手に入れてください。
Access via gopher:
リスを通したアクセス:
Connect to gopher.internic.net and select the menu item:
gopher.internic.netに接続してください、そして、メニュー項目を選択してください:
4. InterNIC Directory and Database Services (AT&T)/
4. InterNICディレクトリとデータベース・サービス(AT&T)/
and then the menu item:
次に、メニュー項目:
3. Documents to be reviewed at the *** IETF
3. ***IETFで見直されるべきドキュメント
One may use the public-access gopher client by:
以下でパブリックアクセスリスクライアントを使用するかもしれません。
telnet gopher.internic.net
telnet gopher.internic.net
Submission of documents via anonymous FTP:
公開FTPを通したドキュメントの提出:
FTP to ds.internic.net and login as anonymous. Change directory to:
ds.internic.netへのFTPと匿名としてのログイン。 以下のことのためにディレクトリを変えてください。
/incoming/current-ietf-docs
/incoming/current-ietf-docs
Put the document using the following filename convention,
以下のファイル名コンベンションを使用して、ドキュメントを置いてください。
<area>.<wgname>.<filename>
e.g.:
<領域><wgname><ファイル名>、例えば:
plenary.mondayVGs.ps
app.osids.agenda
app.osids.internic-talk-VGs.ps
plenary.mondayVGs.ps app.osids.agenda app.osids.internicはVGs.psについて話します。
Huizer & Crocker [Page 22] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[22ページ]RFC1603IETFワーキンググループガイドライン行進1994
Note that the names of areas and working groups are their official short-form acronyms,
領域とワーキンググループの名前がそれらの公式の縮約形頭文字語であることに注意してください。
Submission of documents via electronic mail:
電子メールを通したドキュメントの提出:
Send mail to
メールを送ります。
admin@ds.internic.net
admin@ds.internic.net
with the following subject line:
以下の対象で、立ち並んでください:
IETF - <area>.<wgname>.<filename>
IETF--<領域><wgname><ファイル名>。
e.g.:
例えば:
IETF - app.osids.agenda
IETF--app.osids.agenda
NOTE: Instead of sending a fresh copy of an already available document, you may ask the InterNIC's administrators to create a link to an existing internet-draft/RFC/ID
以下に注意してください。 既に利用可能なドキュメントの新鮮なコピーを送ることの代わりに、あなたは、既存のインターネット草稿/RFC/IDへのリンクを作成するようにInterNICの管理者に頼むことができます。
NOTE: If you do not remember your area or working group acronym get the file /ftp/ietf/1wg-summary.txt from ds.internic.net via anonymous FTP.
以下に注意してください。 領域かワーキンググループ頭文字語を覚えていないなら、ds.internic.netから公開FTPでファイル/ftp/ietf/1wg-summary.txtを手に入れてください。
6.3. Internet-Drafts (I-D)
6.3. インターネット草稿(I-D)
The Internet-Drafts directory is provided to working groups as a resource for posting and disseminating early copies of working group documents. This repository is replicated at various locations around the Internet. It is encouraged that draft documents be posted as soon as they become reasonably stable.
早めのコピーのワーキンググループドキュメントを掲示して、広めるためのリソースとしてインターネット草稿ディレクトリをワーキンググループに提供します。 この倉庫はインターネットの周りの様々な位置で模写されます。 奨励されて、合理的に安定するようになるとすぐに、掲示されていて、それがドキュメントを作成するということです。
It is stressed here that Internet-Drafts are working documents and have no official standards status whatsoever. They may, eventually, turn into a standards-track document or they may sink from sight. Internet-Drafts are submitted to:
ここで、インターネット草稿が働くドキュメントであり、公式の規格状態を全く持っていないと強調されます。結局、標準化過程文書に変わるかもしれませんか、またはそれらは視界から没するかもしれません。 以下のことのためにインターネット草稿を提出します。
internet-drafts@cnri.reston.va.us
internet-drafts@cnri.reston.va.us
The format of an Internet-Draft must be the same as for an RFC [2]. Further, an I-D must contain:
インターネット草稿の形式はRFC[2]のように同じであるに違いありません。 さらに、I-Dは以下を含まなければなりません。
- Beginning, standard, boilerplate text which is provided by
the Secretariat;
- 事務局によって提供される始まっていて、標準の決まり文句のテキスト。
- The I-D filename; and
- I-Dファイル名。 そして
Huizer & Crocker [Page 23] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[23ページ]RFC1603IETFワーキンググループガイドライン行進1994
- The expiration date for the I-D.
- I-Dのための有効期限。
Complete specification of requirements for an Internet-Draft are found in the file:
インターネット草稿のための要件の完全な仕様はファイルで見つけられます:
1id-guidelines.txt
1id-guidelines.txt
in the internet-drafts directory at an Internet Repository site.
インターネットRepositoryサイトのインターネット草稿ディレクトリで。
6.4. Request For Comments (RFC)
6.4. コメントを求める要求(RFC)
The work of an IETF working group usually results in publication of one or more documents, as part of the Request For Comments (RFCs) [2] series. This series is the archival publication record for the Internet community. A document can be written by an individual in a working group, by a group as a whole with a designated Editor, or by others not involved with the IETF. The designated author need not be the group Chair(s).
通常、IETFワーキンググループの仕事は1通以上のドキュメントの公表をもたらします、Request For Comments(RFCs)[2]シリーズの一部として。 このシリーズはインターネットコミュニティのための記録保管所の公表記録です。 個人はワーキンググループでドキュメントを書くことができます、指定されたEditor、またはIETFにかかわらない他のものによるグループ全体で。 指定された作者はグループ議長(s)である必要はありません。
NOTE: The RFC series is a publication mechanism only and publication does not determine the IETF status of a document. Status is determined through separate, explicit status labels assigned by the IESG on behalf of the IETF. In other words, the reader is reminded that all Internet Standards are published as RFCs, but NOT all RFCs specify standards.
以下に注意してください。 RFCシリーズは公表メカニズム専用です、そして、公表はドキュメントのIETF状態を決定しません。 状態はIETFを代表してIESGによって割り当てられた別々の、そして、明白な状態ラベルを通して決定します。 言い換えれば、読者はすべてのRFCsではなく、RFCsが規格を指定するときすべてのインターネットStandardsが発行されるのを思い出させられています。
For a description on the various categories of RFCs the reader is referred to [1, 4, 5, 6].
RFCsの様々なカテゴリにおける記述について、読者は言及されます[1、4、5、6]。
6.5. Submission of documents
6.5. ドキュメントの提出
When a WG decides that a document is ready for publication, the following must be done:
WGが、ドキュメントが公表の準備ができていると決めると、以下をしなければなりません:
- The version of the relevant document as approved by the WG
must be in the Internet-Drafts directory;
- 承認されるとしてのWGによる関連ドキュメントのバージョンがインターネット草稿ディレクトリにあるに違いありません。
- The relevant document must be formatted according to RFC
rules [2].
- RFC規則[2]に従って、関連ドキュメントをフォーマットしなければなりません。
- The WG Chair sends email to the relevant Area Director, with
a copy to the IESG Secretary. The mail should contain the
reference to the document, and the request that it be
progressed as an Informational, Experimental, Prototype or
standards-track (Proposed, Draft or Internet Standard) RFC.
- WG議長はIESG長官へのコピーで関連Areaディレクターにメールを送ります。 メールは、ドキュメントに参照を含んでいて、Informational、Experimental、Prototypeまたは標準化過程としてそれが進行されるという要求を含むべきです。(提案された、DraftかインターネットStandard) RFC。
The IESG Secretary will acknowledge receipt of the email. Unless returned to the WG for further development, progressing of the
IESG長官はメールの領収書を受け取ったことを知らせるでしょう。 さらなる開発のためにWGに返されて、進歩をします。
Huizer & Crocker [Page 24] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[24ページ]RFC1603IETFワーキンググループガイドライン行進1994
document is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor and the WG Chair and Editor.
そして、ドキュメントはIESGの責任です。 IESG承認の後に、最終的な気質への責任はRFC Editor、WG議長、およびEditorの共同責任です。
6.6. Review of documents
6.6. ドキュメントのレビュー
Usually in case of a submission intended as an Informational or Experimental RFC minimal review is necessary. However, if the WG or the RFC Editor thinks that an extensive review is appropriate, the Area Director may be asked to conduct one. This review may either be done by the AD and other IESG participants or the IESG may ask for an independent review (e.g., by someone not part of the WG in question) from the Area Directorate or elsewhere.
通常InformationalかExperimental RFCとして意図する服従の場合には、最小量のレビューが必要です。 しかしながら、WGかRFC Editorが、大量のレビューが適切であると思うなら、Areaディレクターが1つを行うように頼まれるかもしれません。 ADまでにこのレビューをするかもしれません、そして、他のIESG関係者かIESGがほかの場所でArea Directorateから独立しているレビュー(例えば、部分ではなく、問題のWGのだれかによる)を求めるかもしれません。
A review will lead to one of three possible conclusions:
レビューは3つの可能な結論の1つに通じるでしょう:
1. The document is accepted as is.
1. そのままであるとドキュメントを受け入れます。
This fact will be announced by the IESG Secretary to the
IETF mailing list and to the RFC Editor. Publication is then
further handled between the RFC Editor and the author(s).
この事実はIETFメーリングリストとRFC EditorのIESG長官によって発表されるでしょう。 そして、公表はRFC Editorと作者の間でさらに扱われます。
2. Changes regarding content are suggested to the author(s)/WG.
2. 内容に関する変化は作者(s)/WGに示されます。
Suggestions must be clear and direct, so as to facilitate
working group and author correction of the specification.
Once the author(s)/WG have made these changes or have
explained to the satisfaction of the reviewers why the
changes are not necessary, the document will be accepted for
publication as under point 1, above.
提案は、仕様のワーキンググループと作者修正を容易にするために明確であって、ダイレクトでなければなりません。 作者(s)/WGが、いったんこれらの変更を行ったか、または変化はなぜ必要でないかを評論家の満足に説明すると、公表のためにポイント1のようにドキュメントを受け入れるでしょう、上です。
3. The document is rejected.
3. ドキュメントは拒絶されます。
This will need strong and thorough arguments from the
reviewers. The whole IETF and working group process is
structured such that this alternative is not likely to arise
for documents coming from a working group. After all, the
intentions of the document will already have been described
in the WG charter, and reviewed at the start of the WG.
これは評論家から強くて徹底的な議論を必要とするでしょう。 全体のIETFとワーキンググループの過程が構造化されるので、この代替手段はワーキンググループから来るドキュメントのために起こりそうにはありません。 結局、ドキュメントの意志は、既にWG特許で説明されて、WGの始めで見直されてしまうでしょう。
If any individual or group of individuals feels that the review treatment has been unfair, there is the opportunity to make a procedural complaint. The mechanism for procedural complaints is described in the section on Contention and Appeal.
何か個人や個体群が、レビュー処理が不公平であると感じるなら、手続き上の苦情を作る機会があります。 手続き上の苦情のためのメカニズムはContentionとAppealの上のセクションで説明されます。
Before the IESG makes a final decision on a standards-track document, the IESG Secretary will issue a "Last Call" to the IETF mailing list. This Last Call will announce the intention of the IESG to consider
IESGが標準化過程文書の最終決定をする前に、IESG長官は「最後の呼び出し」をIETFメーリングリストに発行するでしょう。 このLast CallはIESGが考えるという意志を発表するでしょう。
Huizer & Crocker [Page 25] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[25ページ]RFC1603IETFワーキンググループガイドライン行進1994
the document, and it will solicit final comments from the IETF within a period of two weeks. It is important to note that a Last Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last Call cannot serve as a more general, in-depth review.
ドキュメント、およびそれは請求するでしょう。期間の2週間以内にIETFから最終的なコメントに請求してください。 インターネットコミュニティとの簡潔で、最終的なチェックとしてLast Callが、どんな重要な関心も逃されてもいませんし、誤解されてもいないのを確実にすることを意図することに注意するのは重要です。 Last Callは、より一般的で、徹底的なレビューとして機能できません。
7. SECURITY CONSIDERATIONS
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. REFERENCES
8. 参照
[1] Internet Architecture Board and Internet Engineering Steering
Group, "The Internet Standards Process -- Revision 2", RFC 1602,
IAB, IESG, March 1994.
[1]運営グループ、インターネット・アーキテクチャ委員会とインターネットの設計している「改正2インチ、RFC1602、IAB、IESG、1994年インターネット標準化過程--3月」。
[2] Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[2] ポステル、J.、「指示、RFCが書く、」、RFC1543、科学が設けるUSC/情報、10月1993日
[3] Malkin, G., and J. Reynolds, "F.Y.I. on F.Y.I. - Introduction to
the F.Y.I. Notes", RFC 1150, Proteon, USC/Information Sciences
Institute, March 1990.
[3] マルキン、G.、およびJ.レイノルズ、「F. Y. I.--序論でのF.Y.I.、F.Y.I.注意、」、RFC1150、Proteon(科学が1990年3月に設けるUSC/情報)
[4] Postel, J., Editor, "Introduction to the STD Notes", RFC 1311,
USC/Information Sciences Institute, March 1992.
[4] ポステル、J.、エディタ、「STD注意への序論」、RFC1311、科学が1992年3月に設けるUSC/情報。
[5] Postel, J., Editor, "Internet Official Protocol Standards", STD
1, RFC 1600, IAB, March 1994.
[5] ポステル、J.、エディタ、「インターネット公式プロトコル標準」、STD1、RFC1600、IAB、1994年3月。
[6] Cerf, V., "The Internet Activities Board", RFC 1160, NRI, May
1990.
[6] サーフ(V.、「インターネット活動板」、RFC1160、NRI)は1990がそうするかもしれません。
Huizer & Crocker [Page 26] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[26ページ]RFC1603IETFワーキンググループガイドライン行進1994
9. AUTHORS' ADDRESSES
9. 作者のアドレス
Erik Huizer
SURFnet bv
P.O. Box 19035
3501 DA Utrecht
The Netherlands
エリックHuizer SURFnet bv P.O. Box19035 3501DAユトレヒトオランダ
Phone: +31 30 310290
Fax: +31 30 340903
EMail: Erik.Huizer@SURFnet.nl
以下に電話をしてください。 +31 30 310290、Fax: +31 30 340903はメールされます: Erik.Huizer@SURFnet.nl
Dave Crocker
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
P.O. Box 7311
Mountain View, CA 94039
デーヴ・医者シリコングラフィックス2011N.海岸線Blvd. マウンテンビュー、P.O. Box7311カリフォルニア 94039
Phone: +1 415 390 1804
Fax: +1 415 962 8404
EMail: dcrocker@sgi.com
以下に電話をしてください。 +1 415 390、1804Fax: +1 8404年の415 962メール: dcrocker@sgi.com
Huizer & Crocker [Page 27] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[27ページ]RFC1603IETFワーキンググループガイドライン行進1994
APPENDIX: SAMPLE WORKING GROUP CHARTER
付録: サンプルワーキンググループ特許
Multiparty Multimedia Session Control (mmusic)
Multipartyマルチメディアセッション制御(mmusic)
Charter
憲章
Chair(s):
Eve Schooler <schooler@isi.edu>
Abel Weinrib <abel@bellcore.com>
議長(s): イブ Schooler <schooler@isi.edu 、gt;、アベルWeinrib<abel@bellcore.com>。
Transport Area Director(s)
Allison Mankin <mankin@cmf.nrl.navy.mil>
領域のディレクターアリソン Mankin <mankin@cmf.nrl.navy.mil を輸送してください、gt。
Mailing lists:
General Discussion:confctrl@isi.edu
To Subscribe: confctrl-request@isi.edu
Archive: venera.isi.edu:~/confctrl/confcrtl.mail
メーリングリスト: 議論: 申し込む一般 confctrl@isi.edu : confctrl-request@isi.edu アーカイブ: venera.isi.edu: ~/confctrl/confcrtl.mail
Description of Working Group:
作業部会の記述:
The demand for Internet teleconferencing has arrived, yet an
infrastructure to support this demand is barely in place.
Multimedia session control, defined as the management and
coordination of multiple sessions and their multiple users in
multiple media (e.g., audio, video), is one component of the
infrastructure. The Multiparty Multimedia Session Control
Working Group is chartered to design and specify a protocol to
perform these functions.
インターネット電子会議の需要は到着しました、しかし、この要求をサポートするインフラストラクチャがほとんど適所でないところにあります。 マルチメディア(例えば、オーディオ、ビデオ)による複数のセッションと彼らの複数のユーザの管理とコーディネートと定義されたマルチメディアセッション制御はインフラストラクチャの1つの成分です。 Multiparty Multimedia Session Control作業部会は、これらの機能を実行するためにプロトコルを設計して、指定するためにチャーターされます。
The protocol will provide negotiation for session membership,
underlying communication topology and media configuration. In
particular, the protocol will support a user initiating a
multimedia multiparty session with other users ("calling" other
users) over the Internet by allowing a teleconferencing
application on one workstation to explicitly rendezvous with
teleconferencing applications running on remote workstations.
Defining a standard protocol will enable session-level
interoperability between different teleconferencing
implementations.
プロトコルはセッション会員資格、基本的なコミュニケーショントポロジー、およびメディア構成のための交渉を提供するでしょう。 特に、プロトコルは電子会議アプリケーションが遠隔ワークステーションで動いていて1台のワークステーションにおける電子会議アプリケーションが明らかに集合するのを許容することによってインターネットの上で他のユーザとのマルチメディア「マルチ-パーティー」セッションを開始する(他のユーザを「呼ぶ」)ユーザをサポートするでしょう。 標準プロトコルを定義すると、異なった電子会議実装の間のセッションレベル相互運用性は可能にされるでしょう。
The focus of the working group is to design a session negotiation
protocol that is tailored to support tightly-controlled
conferences. The MBONE currently carries primarily loosely-
controlled sessions, i.e., sessions with little to no interaction
among members and with no arbitration facility, security, or
coordination of quality-of-service options for time-critical
media. Users may learn of available sessions using the "sd"
utility or other out of band mechanisms (e.g., email). However,
ワーキンググループの焦点はしっかり制御された会議をサポートするために合わせるセッション交渉プロトコルを設計することになっています。 MBONEは現在、時間重要なメディアのためにメンバーの中と、そして、サービスの質オプションの仲裁施設か、セキュリティか、コーディネートなしで主として緩く制御されたセッション、すなわち、少しとのセッションをどんな相互作用までも運びません。 ユーザは、バンドメカニズムから何らかの"sd"ユーティリティを使用することで利用可能なセッションを知るかもしれません(例えば、メールしてください)。 しかしながら
Huizer & Crocker [Page 28] RFC 1603 IETF Working Group Guidelines March 1994
Huizerとクロッカー[28ページ]RFC1603IETFワーキンググループガイドライン行進1994
there is clearly also a need for tightly-controlled sessions that
provide mechanisms for directly contacting other users to
initiate a session and for negotiating conference parameters such
as membership, media encodings and encryption keys. In addition,
these sessions should support renegotiation during a session, for
example to add or delete members or change the media encoding.
It is possible that the protocol will, in the limiting case, also
support loosely-controlled sessions.
明確に、セッションを開始するために直接他のユーザに連絡して、会員資格や、メディアencodingsや暗号化キーなどの会議パラメタを交渉するのにメカニズムを提供するしっかり制御されたセッションの必要もあります。 さらに、これらのセッションは、例えば、加えるか、メンバーを削除するか、またはメディアコード化を変えるためにセッションの間、再交渉をサポートするべきです。 また、プロトコルが制限場合で緩く制御されたセッションをサポートするのは、可能です。
The main goal of the working group will be to specify the session
control protocol for use within teleconferencing software over
the Internet. The working group will focus on the aspects of the
session control problem that are well understood, while keeping
an eye on evolving research issues. Toward this end, the working
group has made an inventory of existing conferencing systems and
their session control protocols. The working group will document
the requirements of the existing prototypes as a basis for the
protocol development. The working group will iteratively refine
the protocol based on implementation and operational experience.
ワーキンググループの第一目的はインターネットの上の電子会議ソフトウェアの中の使用にセッション制御プロトコルを指定することになっているでしょう。 ワーキンググループは研究課題を発展するとき目を光らせている間によく理解されているセッション制御の問題の局面に焦点を合わせるでしょう。 このような目的で、ワーキンググループは既存の会議システムとそれらのセッション制御プロトコルの目録を作りました。 ワーキンググループはプロトコル開発の基礎として既存のプロトタイプの要件を記録するでしょう。 ワーキンググループは繰り返しに実装と運用経験に基づくプロトコルを洗練するでしょう。
Furthermore, the working group will coordinate with other efforts
related to multimedia conferencing, such as directory services
for cataloguing users and conferences, the RTP and RTCP protocols
developed by the Audio/Video Transport Working Group, resource
reservation and management at the network level, and schemes for
multicast address allocation.
その上、他の取り組みがマルチメディア会議に関連する状態で、ワーキンググループは調整されるでしょう、Audio/ビデオTransport作業部会、資源予約、および経営者側がネットワークレベルで発展させたユーザ、会議、RTP、およびRTCPプロトコルをカタログに載せるためのディレクトリサービスや、マルチキャストアドレス配分の体系などのように。
Goals and Milestones:
目標と重大事件:
May 93 Hold an on-line working group meeting to discuss
the conference control framework, the relevant
terminology, a functional taxonomy and how
different conversational styles place
requirements on session protocols.
5月93日のHold、会議コントロールフレームワークと、関連用語と、機能的な分類学と異なった会話体がどうセッションプロトコルに要件を置くかについて議論するオンラインワーキンググループミーティング。
Jun 93 Submit the Conference Session Control Protocol to
the IESG for consideration as an Experimental
Protocol.
Experimentalプロトコルとしての考慮のためのIESGへの6月93日のSubmitコンファレンスSession Controlプロトコル。
Aug 93 Post an Internet-Draft describing the Session
Control Requirements.
8月93日のポスト、Session Control Requirementsについて説明するインターネット草稿。
Nov 93 Post an Internet-Draft of the Session Control
Protocol.
11月93日はセッション制御プロトコルのインターネット草稿を掲示します。
Mar 94 Submit a revised Internet-Draft based on
implementation experience.
改訂されたインターネット草稿が実装経験を基礎づけた3月94日のSubmit。
Huizer & Crocker [Page 29]
Huizerとクロッカー[29ページ]
一覧
スポンサーリンク
