[要約] RFC 2418は、IETFの作業グループのガイドラインと手順に関するドキュメントです。その目的は、IETFの作業グループが効果的に運営されるための指針を提供することです。
Network Working Group S. Bradner
Request for Comments: 2418 Editor
Obsoletes: 1603 Harvard University
BCP: 25 September 1998
Category: Best Current Practice
IETF Working Group Guidelines and Procedures
IETFワーキンググループのガイドラインと手順
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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 also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors.
インターネット技術標準化委員会（IETF）は、インターネット標準として意図された仕様の開発とレビューを担当しています。 IETFの活動は、ワーキンググループ（WG）にまとめられています。このドキュメントでは、IETFワーキンググループの編成と運用に関するガイドラインと手順について説明します。また、IETF参加者WGとインターネットエンジニアリングステアリンググループ（IESG）の間の正式な関係、およびWG議長、WG参加者、IETFエリアディレクターを含むIETF参加者の基本的な義務についても説明します。
Table of Contents
目次
Abstract ......................................................... 1
1. Introduction .................................................. 2
1.1. IETF approach to standardization .......................... 4
1.2. Roles within a Working Group .............................. 4
2. Working group formation ....................................... 4
2.1. Criteria for formation .................................... 4
2.2. Charter ................................................... 6
2.3. Charter review & approval ................................. 8
2.4. Birds of a feather (BOF) .................................. 9
3. Working Group Operation ....................................... 10
3.1. Session planning .......................................... 11
3.2. Session venue ............................................. 11
3.3. Session management ........................................ 13
3.4. Contention and appeals .................................... 15
4. Working Group Termination ..................................... 15
5. Rechartering a Working Group .................................. 15
6. Staff Roles ................................................... 16
6.1. WG Chair .................................................. 16
6.2. WG Secretary .............................................. 18
6.3. Document Editor ........................................... 18
6.4. WG Facilitator ............................................ 18
6.5. Design teams .............................................. 19
6.6. Working Group Consultant .................................. 19
6.7. Area Director ............................................. 19
7. Working Group Documents ....................................... 19
7.1. Session documents ......................................... 19
7.2. Internet-Drafts (I-D) ..................................... 19
7.3. Request For Comments (RFC) ................................ 20
7.4. Working Group Last-Call ................................... 20
7.5. Submission of documents ................................... 21
8. Review of documents ........................................... 21
9. Security Considerations ....................................... 22
10. Acknowledgments .............................................. 23
11. References ................................................... 23
12. Editor's Address ............................................. 23
Appendix: Sample Working Group Charter .......................... 24
Full Copyright Statement ......................................... 26
The Internet, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards. There are also many isolated interconnected networks, which are not connected to the global Internet but use the Internet Standards. Internet Standards are developed in the Internet Engineering Task Force (IETF). This document defines guidelines and procedures for IETF working groups. The Internet Standards Process of the IETF is defined in [1]. The organizations involved in the IETF Standards Process are described in [2] as are the roles of specific individuals.
相互接続された自律ネットワークの緩やかに編成された国際的なコラボレーションであるインターネットは、インターネット標準で定義されたオープンプロトコルと手順への自主的な準拠を通じて、ホスト間の通信をサポートします。また、グローバルなインターネットに接続されていないがインターネット標準を使用している、相互接続された分離されたネットワークも数多くあります。インターネット標準は、Internet Engineering Task Force（IETF）で開発されました。このドキュメントでは、IETFワーキンググループのガイドラインと手順を定義しています。 IETFのインターネット標準プロセスは、[1]で定義されています。 IETF標準プロセスに関与する組織は、特定の個人の役割と同様に[2]で説明されています。
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 primary activities of the IETF are performed by committees known as working groups. There are currently more than 100 working groups. (See the IETF web page for an up-to-date list of IETF Working Groups - http://www.ietf.org.) Working groups tend to have a narrow focus and a lifetime bounded by the completion of a specific set of tasks, although there are exceptions.
IETFは、ネットワーク設計者、オペレーター、ベンダー、ユーザー、およびインターネットとそれに使用されているテクノロジーに関心のある研究者の大規模なオープンコミュニティです。 IETFの主要な活動は、ワーキンググループと呼ばれる委員会によって行われます。現在、100以上のワーキンググループがあります。 （IETFワーキンググループの最新リストについては、IETFのWebページを参照してください-http://www.ietf.org。）ワーキンググループは、特定の一連の作業の完了に限定された、限られた焦点と寿命を持つ傾向があります。例外がありますが、タスク。
For management purposes, the IETF working groups are collected together into areas, with each area having a separate focus. For example, the security area deals with the development of security-related technology. Each IETF area is managed by one or two Area Directors (ADs). There are currently 8 areas in the IETF but the number changes from time to time. (See the IETF web page for a list of the current areas, the Area Directors for each area, and a list of which working groups are assigned to each area.)
管理の目的で、IETFワーキンググループは複数の領域にまとめられ、各領域には個別の焦点があります。たとえば、セキュリティ領域では、セキュリティ関連の技術の開発を扱います。各IETFエリアは、1つまたは2つのエリアディレクター（AD）によって管理されます。現在IETFには8つの領域がありますが、その数は時々変更されます。 （現在のエリアのリスト、各エリアのエリアディレクター、および各エリアに割り当てられているワーキンググループのリストについては、IETF Webページを参照してください。）
In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area.
多くの地域で、エリアディレクターは諮問グループまたはディレクターを形成しています。これらは、IETFの経験豊富なメンバーと、その地域が代表する技術コミュニティで構成されています。各グループの具体的な名前と役割の詳細は地域ごとに異なりますが、主な目的は、これらのグループがエリアディレクターを支援することです（たとえば、エリアで作成された仕様のレビューなど）。
The IETF area directors are selected by a nominating committee, which also selects an overall chair for the IETF. The nominations process is described in [3].
IETFエリアディレクターは指名委員会によって選出され、指名委員会もIETFの全体的な議長を選出します。推薦プロセスは[3]で説明されています。
The area directors sitting as a body, along with the IETF Chair, comprise the Internet Engineering Steering Group (IESG). The IETF Executive Director is an ex-officio participant of the IESG, as are the IAB Chair and a designated Internet Architecture Board (IAB) liaison. The IESG approves IETF Standards and approves the publication of other IETF documents. (See [1].)
IETFの議長と一体となったエリアディレクターがインターネットエンジニアリングステアリンググループ（IESG）を構成します。 IETFのエグゼクティブディレクターは、IEBの議長および指定されたインターネットアーキテクチャボード（IAB）のリエゾンと同様に、IESGの職権上の参加者です。 IESGはIETF標準を承認し、他のIETFドキュメントの発行を承認します。 （[1]を参照してください。）
A small IETF Secretariat provides staff and administrative support for the operation of the IETF.
小さなIETF事務局は、IETFの運営のためにスタッフと管理サポートを提供します。
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 the 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. When used in this document the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [6]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this document to help smooth WG operation and reduce the chance for confusion about the processes.
この文書は、IETFでのワーキンググループの編成と運用に関する手順とガイドラインを定義しています。これは、IETF内の他の組織とのワーキンググループの関係を定義しています。ワーキンググループの運営に関するワーキンググループの議長とエリアディレクターの義務も定められています。このドキュメントで使用されているキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL "はRFC 2119 [6]に記述されているように解釈されます。 RFC 2119は、これらのキーワードの使用を定義して、標準の意図を可能な限り明確に追跡することを目的としています。このドキュメントでは、同じキーワードを使用して、WGの操作を円滑にし、プロセスに関する混乱の可能性を減らしています。
Familiarity with The Internet Standards Process [1] is essential for a complete understanding of the philosophy, procedures and guidelines described in this document.
このドキュメントで説明されている哲学、手順、ガイドラインを完全に理解するには、インターネット標準プロセス[1]に精通していることが不可欠です。
The document, "Organizations Involved in the IETF Standards Process" [2] describes the roles of a number of individuals within a working group, including the working group chair and the document editor. These descriptions are expanded later in this document.
ドキュメント「IETF標準プロセスに関与する組織」[2]は、ワーキンググループの議長やドキュメントエディターなど、ワーキンググループ内の多数の個人の役割を説明しています。これらの説明は、このドキュメントの後半で拡張されます。
IETF working groups (WGs) are the primary mechanism for development of IETF specifications and guidelines, many of which are intended to be standards or recommendations. A working group may be established at the initiative of an Area Director 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 IETF Area Director(s) in whose area the working group would fall and MUST proceed through the formal steps detailed in this section.
IETFワーキンググループ（WG）は、IETF仕様とガイドラインを開発するための主要なメカニズムであり、その多くは標準または推奨事項となることを目的としています。ワーキンググループは、エリアディレクターの主導で設立される場合と、個人または個人のグループによって開始される場合があります。 IETFワーキンググループの作成に関心のある方は、ワーキンググループが該当する領域のIETFエリアディレクターのアドバイスと同意を得なければならず、このセクションで説明する正式な手順を実行する必要があります。
Working groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Working groups are generally expected to be short-lived in nature. Upon completion of its goals and achievement of its objectives, the working group is terminated. A working group may also be terminated for other reasons (see section 4). Alternatively, with the concurrence of the IESG, Area Director, the WG Chair, and the WG participants, the objectives or assignment of the working group may be extended by modifying the working group's charter through a rechartering process (see section 5).
ワーキンググループは通常、特定の問題に対処するため、または1つ以上の特定の成果物（ガイドライン、標準仕様など）を作成するために作成されます。ワーキンググループは、一般的に短期的であると予想されます。目標が達成され、目標が達成されると、ワーキンググループは終了します。ワーキンググループは、他の理由で終了することもあります（セクション4を参照）。あるいは、IESG、エリアディレクター、WG議長、およびWG参加者の同意を得て、再チャーティングプロセスを通じてワーキンググループのチャーターを変更することにより、ワーキンググループの目的または割り当てを拡張できます（セクション5を参照）。
When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues:
ワーキンググループを作成することが適切かどうかを判断する場合、エリアディレクターとIESGはいくつかの問題を検討します。
- Are the issues that the working group plans to address clear and relevant to the Internet community?
- ワーキンググループが取り組む予定の問題は明確で、インターネットコミュニティに関連していますか？
- Are the goals specific and reasonably achievable, and achievable within a reasonable time frame?
- 目標は具体的かつ合理的に達成可能であり、妥当な期間内に達成可能ですか？
- What are the risks and urgency of the work, to determine the level of effort 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.
- ワーキンググループの活動は他のワーキンググループの活動と重複していますか？その場合、ワーキンググループを作成するのが適切な場合もありますが、細分する作業によって利用可能な技術的専門知識が薄れることが多いため、この質問はエリアディレクターが慎重に検討する必要があります。
- Is there sufficient interest within the IETF in the working group's topic with enough 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 contributing to the document text. IETF experience suggests that these roles typically cannot all be handled by one person; a minimum of four or five active participants in the management positions are typically required in addition to a minimum of one or two dozen people that will attend the working group meetings and contribute on the mailing list. NOTE: The interest must be broad enough that a working group would not be seen as merely the activity of a single vendor.
- IETF内でワーキンググループのトピックに十分な関心があり、希望する結果（プロトコルの仕様など）を生み出すために努力を惜しまない人々がいますか？ワーキンググループは、ワーキンググループプロセスの管理、ワーキンググループドキュメントの編集、ドキュメントテキストへの貢献など、かなりの労力を必要とします。 IETFの経験では、これらの役割のすべてを1人で処理することは通常不可能であることが示唆されています。ワーキンググループミーティングに参加してメーリングリストに参加する最低1〜20人に加えて、通常、管理職に最低4〜5人のアクティブな参加者が必要です。注：関心は、ワーキンググループが単一のベンダーの活動と見なされないように十分に広いものでなければなりません。
- Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group?
- IETF内のワーキンググループのトピックに関する十分な専門知識はありますか。また、ワーキンググループへの貢献に関心のある人々はいますか。
- 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プロセスへのエンドユーザーの参加と、直接的でない手段によって測定できます。
- Does the IETF have a reasonable role to play in the determination of the technology? There are many Internet-related technologies that may be interesting to IETF members but in some cases the IETF may not be in a position to effect the course of the technology in the "real world". This can happen, for example, if the technology is being developed by another standards body or an industry consortium.
- IETFは、テクノロジーの決定において果たすべき妥当な役割を果たしていますか？ IETFのメンバーにとって興味深いインターネット関連のテクノロジーはたくさんありますが、場合によっては、IETFが「現実の世界」でテクノロジーの流れに影響を与えることができない場合があります。これは、たとえば、テクノロジが別の標準化団体または業界コンソーシアムによって開発されている場合に発生する可能性があります。
- Are all known intellectual property rights relevant to the proposed working group's efforts issues understood?
- 提案されたワーキンググループの取り組みの問題に関連する既知のすべての知的財産権は理解されていますか？
- Is the proposed work plan an open IETF effort or is it an attempt to "bless" non-IETF technology where the effect of input from IETF participants may be limited?
- 提案された作業計画はオープンなIETFの取り組みですか、それともIETF参加者からの入力の影響が制限される可能性がある非IETFテクノロジを「祝福」する試みですか？
- Is there a good understanding of any existing work that is relevant to the topics that the proposed working group is to pursue? This includes work within the IETF and elsewhere.
- 提案されたワーキンググループが追求するトピックに関連する既存の作業を十分に理解していますか？これには、IETF内および他の場所での作業が含まれます。
- Do the working group's goals overlap with known work in another standards body, and if so is adequate liaison in place?
- ワーキンググループの目標は、別の標準化団体での既知の作業と重複していますか？そうであれば、適切な連絡が適切に行われていますか？
Considering the above criteria, the Area Director(s), using his or her best judgement, will decide whether to pursue the formation of the group through the chartering process.
上記の基準を考慮して、エリアディレクターは最善の判断で、チャータープロセスを通じてグループの形成を進めるかどうかを決定します。
The formation of a working group requires a charter which is primarily negotiated between a prospective working group Chair and the relevant Area Director(s), although final approval is made by the IESG with advice from 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:
ワーキンググループの結成には、将来のワーキンググループチェアと関連するエリアディレクターとの間で主に交渉される憲章が必要ですが、最終承認はIESGによってインターネットアーキテクチャボード（IAB）からの助言を得て行われます。チャーターは、一連のタスクを実行するためのワーキンググループとIETF間の契約です。チャーター：
1. Lists relevant administrative information for the working group; 2. Specifies the direction or objectives of the working group and describes the approach that will be taken to achieve the goals; and 3. Enumerates a set of milestones together with time frames for their completion.
1. ワーキンググループに関連する管理情報をリストします。 2.ワーキンググループの方向性または目的を指定し、目標を達成するために取られるアプローチを説明します。および3.一連のマイルストーンとその完了の時間枠を列挙します。
When the prospective Chair(s), the Area Director and the IETF Secretariat are satisfied with the charter form and content, it becomes the basis for forming a working group. Note that an Area Director MAY require holding an exploratory Birds of a Feather (BOF) meeting, as described below, to gage the level of support for a working group before submitting the charter to the IESG and IAB for approval.
議長候補者、エリアディレクター、IETF事務局がチャーターフォームと内容に満足すると、ワーキンググループを形成するための基礎になります。エリアディレクターは、チャーターを承認のためにIESGおよびIABに提出する前に、ワーキンググループのサポートのレベルを評価するために、以下に説明するように探索鳥の羽（BOF）ミーティングを開催する必要があることに注意してください。
Charters may be renegotiated periodically to reflect the current status, organization or goals of the working group (see section 5). Hence, a charter is a contract between the IETF and the working group which is committing to meet explicit milestones and delivering specific "products".
憲章は定期的に再交渉され、ワーキンググループの現状、組織、または目標を反映します（セクション5を参照）。したがって、チャーターは、明確なマイルストーンに対応し、特定の「製品」を提供することを約束しているIETFとワーキンググループの間の契約です。
Specifically, each charter consists of the following sections:
具体的には、各チャーターは次のセクションで構成されています。
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) The working group may have one or more Chairs to perform the administrative functions of the group. The email address(es) of the Chair(s) shall be included. Generally, a working group is limited to two chairs.
議長ワーキンググループは、グループの管理機能を実行するために1人以上の議長を持つことができます。議長のメールアドレスが含まれます。一般的に、ワーキンググループは2つの椅子に制限されています。
Area and Area Director(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(s).
Area and Area Director（s）ワーキンググループが所属するIETFエリアの名前、および関連するArea Directorの名前と電子メールアドレス。
Responsible Area Director The Area Director who acts as the primary IESG contact for the working group.
担当エリアディレクターワーキンググループの主要なIESG連絡先として機能するエリアディレクター。
Mailing list An IETF working group MUST have a general Internet mailing list. Most of the work of an IETF working group will be conducted on the mailing list. The working group charter MUST include:
メーリングリストIETFワーキンググループには、一般的なインターネットメーリングリストが必要です。 IETFワーキンググループの作業のほとんどは、メーリングリストで行われます。ワーキンググループ憲章は以下を含まなければなりません：
1. The address to which a participant sends a subscription request and the procedures to follow when subscribing,
1. 参加者がサブスクリプション要求を送信するアドレスと、サブスクライブするときに従う手順、
2. The address to which a participant sends submissions and special procedures, if any, and
2. 参加者が提出物と特別な手順（ある場合）を送信するアドレス、および
3. The location of the mailing list archive. A message archive MUST be maintained in a public place which can be accessed via FTP or via the web.
3. メーリングリストのアーカイブの場所。メッセージアーカイブは、FTPまたはWeb経由でアクセスできる公共の場所で維持する必要があります。
As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address "wg_acronym-archive@lists.ietf.org" (where "wg_acronym" is the working group acronym) in the mailing list in order that a copy of all mailing list messages be recorded in the Secretariat's archive. Those archives are located at ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat.
IETF事務局は、コミュニティへのサービスとして、ワーキンググループのメーリングリスト用のメーリングリストアーカイブを運営しています。このサービスを利用するために、ワーキンググループのメーリングリストは、すべてのコピーを作成するために、メーリングリストにアドレス「wg_acronym-archive@lists.ietf.org」（「wg_acronym」はワーキンググループの頭字語）を含める必要があります。メーリングリストのメッセージは事務局のアーカイブに記録されます。これらのアーカイブは、ftp：//ftp.ietf.org/ietf-mail-archiveにあります。堅牢性のために、WGは事務局によって維持されるものとは別の追加のアーカイブを維持する必要があります（SHOULD）。
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 can be used as an overview of the working group's effort.
ワーキンググループの説明グループの焦点と意図を簡単に説明します。このセクションを単独で読むことにより、個人はこのグループが自分の仕事に関連しているかどうかを判断できるはずです。最初のパラグラフは、ワーキンググループのために計画された問題の領域、根拠、目標およびアプローチの簡単な要約を提供しなければなりません。この段落は、ワーキンググループの取り組みの概要として使用できます。
To facilitate evaluation of the intended work and to provide on-going guidance to the working group, the charter must describe the problem being solved and should discuss objectives and expected impact with respect to:
目的の作業の評価を容易にし、進行中のガイダンスをワーキンググループに提供するために、チャーターは解決されている問題を説明し、以下に関して目標と予想される影響について議論する必要があります。
- Architecture - Operations - Security - Network management - Scaling - Transition (where applicable)
- アーキテクチャ-オペレーション-セキュリティ-ネットワーク管理-スケーリング-移行（該当する場合）
Goals and milestones The working group charter MUST establish a timetable for specific work items. While this may be renegotiated 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 (see section 5).
目標とマイルストーンワーキンググループ憲章は、特定の作業項目のスケジュールを確立する必要があります。これは時間の経過とともに再交渉される可能性がありますが、マイルストーンと日付のリストは、エリアディレクターによるワーキンググループの進捗状況とステータスの追跡を容易にし、潜在的な参加者がインプットの重要な瞬間を特定するために不可欠です。マイルストーンは、特定の成果を示すと見なすことができる成果物で構成されます。たとえば、「インターネットドラフト終了」は問題ありませんが、「電子メールによるディスカッション」は問題です。 3〜6か月ごとにマイルストーンを指定すると、進行状況を簡単に測定できるので便利です。このマイルストーンリストは定期的に更新される予定です（セクション5を参照）。
An example of a WG charter is included as Appendix A.
WG憲章の例は、付録Aに含まれています。
Proposed 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 a Consultant from among the ranks of senior IETF participants. (Consultants are described in section 6.) At the discretion of the Area Director, approval of a new WG may be withheld in the absence of sufficient consultant resources.
提案されたワーキンググループは、多くの場合、インターネットアーキテクチャまたはIETFプロセスの歴史に精通していない技術的に有能な参加者で構成されています。残念ながら、これは悪い設計についてのワーキンググループのコンセンサスにつながる可能性があります。ワーキンググループの取り組みを促進するために、エリアディレクターは、上級IETF参加者のランクの中からコンサルタントを割り当てることができます。 （コンサルタントはセクション6で説明されています。）エリアディレクターの裁量により、十分なコンサルタントリソースがない場合、新しいWGの承認が保留されることがあります。
Once the Area Director (and the Area Directorate, as the Area Director deems appropriate) has approved the working group charter, the charter is submitted for review by the IAB and approval by the IESG. After a review period of at least a week the proposed charter is posted to the IETF-announce mailing list as a public notice that the formation of the working group is being considered. At the same time the proposed charter is also posted to the "new-work" mailing list. This mailing list has been created to let qualified representatives from other standards organizations know about pending IETF working groups. After another review period lasting at least a week the IESG MAY approve the charter as-is, it MAY request that changes be made in the charter, or MAY decline to approve chartering of the working group
エリアディレクター（およびエリアディレクターは、エリアディレクターが適切であると考える場合）がワーキンググループの憲章を承認すると、チャーターはIABによるレビューとIESGによる承認のために提出されます。少なくとも1週間のレビュー期間後、提案されたチャーターは、ワーキンググループの編成が検討されていることの公衆通知としてIETFアナウンスメーリングリストに投稿されます。同時に、チャーター案は「新作」のメーリングリストにも掲載されます。このメーリングリストは、他の標準化団体の資格のある代表者に、保留中のIETFワーキンググループについて知らせるために作成されました。 IESGは、少なくとも1週間続くレビュー期間後、チャーターを現状のまま承認する場合があります。チャーターに変更を加えることを要求するか、ワーキンググループのチャーターを承認しない場合があります。
If the IESG approves the formation of the working group it remands the approved charter to the IETF Secretariat who records and enters the information into the IETF tracking database. The working group is announced to the IETF-announce a by the IETF Secretariat.
IESGがワーキンググループの編成を承認した場合、承認された憲章をIETF事務局に差し戻し、IETF事務局は情報を記録してIETF追跡データベースに入力します。ワーキンググループは、IETF事務局によってIETFにアナウンスされます。
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. In addition, a BOF may serve as a forum for a single presentation or discussion, without any intent to form a working group.
多くの場合、問題がワーキンググループの形成に値するかどうかは明確ではありません。問題の調査を容易にするために、IETFは、Birds of a Feather（BOF）セッションの可能性と、予備的な議論のための電子メールリストの早期形成を提供します。さらに、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 a relevant Area Director who must approve a BOF before it can be scheduled. The person who requests the BOF may be asked to serve as Chair of the BOF.
BOFは、「市場調査」と技術的な「ブレーンストーミング」を許可するIETF会議のセッションです。任意の個人が、対象についてBOFを保持する許可を要求できます。リクエストは、BOFをスケジュールする前にBOFを承認する必要がある関連エリアディレクターに提出する必要があります。 BOFを要求する人は、BOFの議長を務めるよう求められる場合があります。
The Chair of the BOF is also responsible for providing a report on the outcome of the BOF. If the Area Director approves, the BOF is then scheduled by submitting a request to agenda@ietf.org with copies to the Area Director(s). A BOF description and agenda are required before a BOF can be scheduled.
BOFの議長は、BOFの結果に関するレポートを提供する責任もあります。エリアディレクターが承認した場合、BOFはagenda@ietf.orgにリクエストを提出し、コピーをエリアディレクターに提出します。 BOFをスケジュールする前に、BOFの説明とアジェンダが必要です。
Available time for BOFs is limited, and BOFs are held at the discretion of the ADs for an area. The AD(s) may require additional assurances before authorizing a BOF. For example,
BOFの利用可能時間には制限があり、BOFはエリアのADの裁量で保持されます。 ADは、BOFを承認する前に追加の保証を必要とする場合があります。例えば、
- The Area Director MAY require the establishment of an open email list 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.
- エリアディレクターは、BOFを承認する前に、オープンメーリングリストの作成を要求する場合があります。これにより、BOFで費やされる時間をより生産的にするために、最初の交換とフレームワーク、語彙、アプローチの共有が可能になります。
- The Area Director MAY require that a BOF be held, prior to establishing a working group (see section 2.2).
- エリアディレクターは、ワーキンググループを設立する前に、BOFの開催を要求することができます（セクション2.2を参照）。
- The Area Director MAY require that there be a draft of the WG charter prior to holding a BOF.
- エリアディレクターは、BOFを開催する前にWG憲章の草案があることを要求する場合があります。
- The Area Director MAY require that a BOF not be held until an Internet-Draft describing the proposed technology has been published so it can be used as a basis for discussion in the BOF.
- エリアディレクターは、BOFでの議論の基礎として使用できるように、提案された技術を説明するインターネットドラフトが公開されるまでBOFを開催しないことを要求できます（MAY）。
In general, a BOF on a particular topic is held only once (ONE slot at one IETF Plenary meeting). Under unusual circumstances Area Directors may, at their discretion, allow a BOF to meet for a second time. BOFs are not permitted to meet three times. Note that all other things being equal, WGs will be given priority for meeting space over BOFs. Also, occasionally BOFs may be held for other purposes than to discuss formation of a working group.
一般に、特定のトピックに関するBOFは1回だけ開催されます（1回のIETF総会で1スロット）。異常な状況下では、エリアディレクターは自らの裁量で、BOFの2回目の会議を許可する場合があります。 BOFは3回会合することはできません。他のすべての条件が等しい場合、WGはBOFよりも会議スペースの優先順位が高くなることに注意してください。また、BOFは、ワーキンググループの形成について話し合う以外の目的で開催されることもあります。
Usually the outcome of a BOF will be one of the following:
通常、BOFの結果は次のいずれかになります。
- There was enough interest and focus in the subject to warrant the formation of a WG;
- WGの結成を正当化するのに十分な関心と集中力があった。
- While there was a reasonable level of interest expressed in the BOF some other criteria for working group formation was not met (see section 2.1).
- BOFで表明された妥当なレベルの関心はありましたが、ワーキンググループ形成に関する他のいくつかの基準が満たされていませんでした（セクション2.1を参照）。
- 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の形成を正当化するのに十分な関心が主題にありませんでした。
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". WG participants should specifically note the requirements for disclosure of conflicts of interest in [2].
IETFには、オープンで公正な参加と、技術的な代替案の徹底的な検討のための基本的な要件があります。これらの制約内では、ワーキンググループは自律的であり、それぞれがセッションへの参加、終了への到達などに関して、自身の運用の詳細のほとんどを決定します。運用の基本ルールは、承認または合意はワーキンググループの「大まかなコンセンサス」によって達成されることです。 WG参加者は、[2]における利益相反の開示の要件に特に注意する必要があります。
A number of procedural questions and issues will arise over time, and it is the function of the Working Group Chair(s) 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 has evolved over time that have proven successful. These are listed here, with actual choices typically determined by the working group participants and the Chair(s).
ワーキンググループの活動を組織または実施する上での厳格なルールはほとんどありませんが、一連のガイドラインと実践は時間とともに進化し、成功を収めています。これらはここにリストされていますが、実際の選択肢は通常、ワーキンググループの参加者と議長によって決定されます。
For coordinated, structured WG interactions, the Chair(s) MUST publish a draft agenda well in advance of the actual session. The agenda should contain at least:
調整され、構造化されたWGの相互作用については、議長は実際のセッションのかなり前に議題案を公開しなければなりません。議題には少なくとも以下を含める必要があります。
- The items for discussion; - The estimated time necessary per item; and - A clear indication of what documents the participants will need to read before the session in order to be well prepared.
- 議論のためのアイテム。 -アイテムごとに必要な推定時間。 -準備を整えるために参加者がセッションの前に読む必要のあるドキュメントの明確な指示。
Publication of the working group agenda shall include sending a copy of the agenda to the working group mailing list and to agenda@ietf.org.
ワーキンググループの議題の公開には、議題のコピーをワーキンググループのメーリングリストとagenda@ietf.orgに送信することが含まれます。
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. IETF Plenary meetings are the primary venue for these face-to-face working group sessions, and it is common (though not required) that active "interim" face-to-face meetings, telephone conferences, or video conferences may also be held. Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings.
すべてのワーキンググループの行動は公開フォーラムで行われ、幅広い参加が奨励されます。ワーキンググループは、電子メール配布リストを介してビジネスの多くを行いますが、定期的に会合して、タスクのステータスと進行状況について話し合い、レビューし、特定の問題を解決し、将来の活動を指揮することがあります。 IETF全体会議は、これらの対面ワーキンググループセッションの主要な開催地であり、アクティブな「中間」対面会議、電話会議、またはビデオ会議も開催されることが一般的です（必須ではありません）。中間会議は、他のワーキンググループ会議に適用される事前通知、報告、オープンな参加、およびプロセスと同じ規則に従います。
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: minutes@ietf.org
すべてのワーキンググループセッション（IETFミーティング以外で開催されるセッションを含む）は、議事録を用意して報告します。これらの議事録には、セッションの議題、行われた決定を含むディスカッションのアカウント、および出席者のリストを含める必要があります。ワーキンググループチェアは、議事録が作成および配布されることを保証する責任がありますが、実際のタスクはワーキンググループチェアによって指定された誰かが実行する場合があります。議事録は、印刷可能なASCIIテキストで提出して、IETF Proceedingsでの公開、およびIETFディレクトリへの投稿に使用し、次の宛先に送信します：minutes@ietf.org
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. Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list.
各ワーキンググループは、マイルストーンを達成するために適切な電子メールと対面のセッションのバランスを決定します。電子メールは、幅広い参加を可能にします。多くの場合、対面の会議ではより適切に焦点を絞ることができるため、ワーキンググループの参加者の中核者の間で合意に達するための効率が高くなります。バランスを決定する際、WGは、そのプロセスが電子メールのみの参加者による貢献を除外しないように機能することを確認する必要があります。メーリングリストで議論されていない、または以前に到着したメーリングリストのコンセンサスと大幅に異なるトピックや問題について、対面のミーティング中に達した決定は、メーリングリストで確認する必要があります。
IETF Meetings 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 facilitate schedule coordination for WGs requiring the same set of experts.
IETF会議WGがIETF会議でのセッションを必要とする場合、IETF会議の最初の発表がIETF事務局によってWG議長リストに行われるとすぐに、議長はタイムスロットを申請する必要があります。 IETFミーティングではセッション時間が不足しているため、リクエストを早期に送信すると、同じ専門家を必要とするWGのスケジュール調整が容易になります。
The application for a WG session at an IETF meeting MUST be made to the IETF Secretariat at the address agenda@ietf.org. Some Area Directors may want to coordinate WG sessions in their area and request that time slots be coordinated through them. If this is the case it will be noted in the IETF meeting announcement. A WG scheduling request MUST contain:
IETF会議でのWGセッションの申請は、アドレスagenda@ietf.orgのIETF事務局に行わなければなりません。一部のエリアディレクターは、自分のエリアでWGセッションを調整し、タイムスロットの調整を要求する場合があります。これが事実である場合、それはIETF会議の発表に記載されます。 WGスケジューリング要求には、以下が含まれている必要があります。
- The working group name and full title; - The amount of time requested; - The rough outline of the WG agenda that is expected to be covered; - The estimated number of people that will attend the WG session; - Related WGs that should not be scheduled for the same time slot(s); and - Optionally a request can be added for the WG session to be transmitted over the Internet in audio and video.
- ワーキンググループの名前と完全なタイトル。 -要求された時間。 -カバーされることが期待されるWG議題の大まかな概要。 -WGセッションに参加する推定人数。 -同じ時間帯にスケジュールされるべきではない関連WG;および-オプションで、WGセッションのリクエストを追加して、オーディオとビデオでインターネット経由で送信できます。
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, or who, in the opinion of the Chair is disrupting the WG process. The Chair should consult with the Area Director(s) if the individual persists in disruptive behavior.
注：作業部会の成功にはオープンな議論と貢献が不可欠ですが、議長は前進を確実にする責任があります。 WGに受け入れられる場合、議長は、進捗を達成するために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.
オンライン公開されたスケジュールと議題、進行中の要約とコンセンサスポーリングを使用して、対面のセッションと同じ方法で電子メールのやり取りを行うことは非常に便利です。
Many working group participants hold that mailing list discussion is the best place to consider and resolve issues and make decisions. The 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会議に出席するよりもはるかに広い範囲の関係者がインターネットメールディスカッションを行うことができることに注意することが重要です。
As with face-to-face sessions occasionally one or more individuals may engage in behavior on a mailing list which disrupts the WG's progress. In these cases the Chair should attempt to discourage the behavior by communication directly with the offending individual rather than on the open mailing list. If the behavior persists then the Chair must involve the Area Director in the issue. As a last resort and after explicit warnings, the Area Director, with the approval of the IESG, may request that the mailing list maintainer block the ability of the offending individual to post to the mailing list. (If the mailing list software permits this type of operation.) Even if this is done, the individual must not be prevented from receiving messages posted to the list. Other methods of mailing list control may be considered but must be approved by the AD(s) and the IESG.
対面式のセッションと同様に、1人以上の個人がメーリングリストで行動し、WGの進捗を妨げることがあります。これらの場合、議長はオープンなメーリングリストではなく、問題のある個人と直接連絡を取り、行動を阻止するよう努めるべきです。行動が続く場合、議長は問題にエリアディレクターを関与させる必要があります。最後の手段として、明示的な警告の後、エリアディレクターは、IESGの承認を得て、メーリングリストのメンテナーに、問題のある個人がメーリングリストに投稿する機能をブロックするよう要求することができます。 （メーリングリストソフトウェアがこの種の操作を許可する場合。）これが行われたとしても、リストに投稿されたメッセージの受信を個人が妨げられてはなりません。メーリングリストを制御する他の方法も検討できますが、ADとIESGによる承認が必要です。
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 a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached.
ワーキンググループは、「大まかなコンセンサス」プロセスを通じて意思決定を行います。 IETFのコンセンサスでは、すべての参加者が同意する必要はありませんが、これはもちろん望ましいことです。一般に、ワーキンググループの支配的な見方が優先されます。 （ただし、「優位性」は量や持続性に基づいて決定されるのではなく、より一般的な合意の感覚に基づいて決定されることに注意する必要があります。）コンセンサスは、手の表示、ハミング、またはその他の手段によって決定できます。 WGが同意する（もちろん大まかなコンセンサスによって）。ワーキンググループの51％は「大まかなコンセンサス」として認定されておらず、99％は大まかなコンセンサスよりも優れていることに注意してください。大まかなコンセンサスに達したかどうかを判断するのは議長次第です。
It can be particularly challenging to gauge the level of consensus on a mailing list. There are two different cases where a working group may be trying to understand the level of consensus via a mailing list discussion. But in both cases the volume of messages on a topic is not, by itself, a good indicator of consensus since one or two individuals may be generating much of the traffic.
メーリングリストのコンセンサスのレベルを評価することは、特に難しい場合があります。ワーキンググループがメーリングリストのディスカッションを通じてコンセンサスのレベルを理解しようとしている2つの異なるケースがあります。ただし、どちらの場合も、1人または2人の個人が大量のトラフィックを生成している可能性があるため、トピックに関するメッセージの量自体は、コンセンサスの良い指標ではありません。
In the case where a consensus which has been reached during a face-to-face meeting is being verified on a mailing list the people who were in the meeting and expressed agreement must be taken into account. If there were 100 people in a meeting and only a few people on the mailing list disagree with the consensus of the meeting then the consensus should be seen as being verified. Note that enough time should be given to the verification process for the mailing list readers to understand and consider any objections that may be raised on the list. The normal two week last-call period should be sufficient for this.
対面式の会議中に到達したコンセンサスがメーリングリストで確認されている場合、会議に参加し、同意を表明した人を考慮に入れる必要があります。会議に100人の参加者がいて、メーリングリストの数人だけが会議のコンセンサスに同意しない場合、コンセンサスは検証済みと見なされます。メーリングリストの読者がリストで提起される可能性のある異議を理解して検討するために、検証プロセスに十分な時間を与える必要があることに注意してください。これには通常の2週間の最終呼び出し期間で十分です。
The other case is where the discussion has been held entirely over the mailing list. The determination of the level of consensus may be harder to do in this case since most people subscribed to mailing lists do not actively participate in discussions on the list. It is left to the discretion of the working group chair how to evaluate the level of consensus. The most common method used is for the working group chair to state what he or she believes to be the consensus view and. at the same time, requests comments from the list about the stated conclusion.
もう1つのケースは、議論がメーリングリスト全体で行われた場合です。この場合、メーリングリストに登録しているほとんどの人はリストのディスカッションに積極的に参加していないため、コンセンサスのレベルを決定するのは難しいかもしれません。コンセンサスのレベルをどのように評価するかはワーキンググループの議長の裁量に任されています。使用される最も一般的な方法は、ワーキンググループの議長がコンセンサスビューであると彼または彼女が信じるものを述べることです。同時に、述べられた結論についてリストにコメントを要求します。
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.
ワーキンググループセッションを管理するための課題は、問題をオープンかつ公正に検討する必要性と、前進する必要性のバランスをとることです。ワーキンググループは全体として、このバランスをとる最終的な責任があります。議長はプロセスを監督する責任がありますが、直接プロセス管理を正式に指名されたファシリテーターに委任する場合があります。
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 decide 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;
古い入力は、既に解決されており、以前に利用できた情報と重複しているトピックに関連しています。
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.
スコープ入力はワーキンググループ憲章のスコープ外です。
Disputes are possible at various stages during the IETF process. As much as possible the process is designed so that compromises can be made, and genuine consensus achieved; however, there are times when even the most reasonable and knowledgeable people are unable to agree. To achieve the goals of openness and fairness, such conflicts must be resolved by a process of open review and discussion.
紛争は、IETFプロセスのさまざまな段階で発生する可能性があります。プロセスは可能な限り妥協が可能で、真のコンセンサスが得られるように設計されています。ただし、最も合理的で知識のある人々でさえ同意できない場合があります。開放性と公平性の目標を達成するには、そのような対立は、オープンなレビューと議論のプロセスによって解決されなければなりません。
Formal procedures for requesting a review of WG, Chair, Area Director or IESG actions and conducting appeals are documented in The Internet Standards Process [1].
WG、議長、エリアディレクター、またはIESGアクションのレビューを要求し、異議申し立てを行うための正式な手順は、インターネット標準プロセス[1]に文書化されています。
Working groups are typically chartered to accomplish a specific task or tasks. After the tasks are complete, the group will be disbanded. However, if a WG produces a Proposed or Draft Standard, the WG will frequently become dormant rather than disband (i.e., the WG will no longer conduct formal activities, but the mailing list will remain available to review the work as it moves to Draft Standard and Standard status.)
ワーキンググループは通常、特定のタスクを実行するためにチャーターされます。タスクが完了すると、グループは解散されます。ただし、WGが標準案またはドラフト標準を作成する場合、WGは解散するのではなく休止状態になることが多い（つまり、WGは正式な活動を行わなくなりますが、メーリングリストは、標準ドラフトに移行するときに作業をレビューするために引き続き利用できます）および標準ステータス。）
If, at some point, it becomes evident that a working group is unable to complete the work outlined in the charter, or if the assumptions which that work was based have been modified in discussion or by experience, the Area Director, in consultation with the working group can either:
ある時点で、作業部会が憲章に概説された作業を完了できないことが明らかになった場合、またはその作業の基礎となった仮定が議論または経験によって変更された場合、エリアディレクターは、ワーキンググループは次のいずれかを実行できます。
1. Recharter to refocus its tasks, 2. Choose new Chair(s), or 3. Disband.
1. 再充電して、そのタスクに再び焦点を当てます。2。新しい椅子を選択します。
If the working group disagrees with the Area Director's choice, it may appeal to the IESG (see section 3.4).
ワーキンググループがエリアディレクターの選択に同意しない場合は、IESGに上訴することができます（セクション3.4を参照）。
Updated milestones are renegotiated with the Area Director and the IESG, as needed, and then are submitted to the IESG Secretariat: iesg-secretary@ietf.org.
更新されたマイルストーンは、必要に応じてエリアディレクターおよびIESGと再交渉され、IESG事務局（iesg-secretary@ietf.org）に提出されます。
Rechartering (other than revising milestones) a working group follows the same procedures that the initial chartering does (see section 2). The revised charter must be submitted to the IESG and IAB for approval. As with the initial chartering, the IESG may approve new charter as-is, it may request that changes be made in the new charter (including having the Working Group continue to use the old charter), or it may decline to approve the rechartered working group. In the latter case, the working group is disbanded.
再チャーター（マイルストーンの改訂を除く）は、最初のチャーターと同じ手順に従います（セクション2を参照）。改訂された憲章は、承認を受けるためにIESGおよびIABに提出する必要があります。最初のチャーターと同様に、IESGは新しいチャーターをそのまま承認する場合があります。新しいチャーターに変更を加えることを要求する場合があります（ワーキンググループが古いチャーターを継続して使用することを含む）、または再チャーターした労働者の承認を拒否する場合があります。グループ。後者の場合、ワーキンググループは解散されます。
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. The Area Director must agree to the specific people performing the WG Chair, and Working Group Consultant roles, and they serve at the discretion of the Area Director.
ワーキンググループはかなりの注意と養育を必要とします。一般的な参加に加えて、成功したワーキンググループは、特定の機能的役割を果たす参加者の努力から利益を得ます。エリアディレクターは、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.
ワーキンググループチェアは、公正でオープンなプロセスを通じて前進することに関心があり、WGビジネスの実施において幅広い裁量権を持っています。議長は、直接またはタスクに割り当てられた他の人が実行するタスクの数を確認する必要があります。
The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention.
議長は、IETFの規則に従って、ワーキンググループのプロセスと人員配置のすべての問題に関して、ワーキンググループに代わって決定を行う責任と権限を持っています。 ADには、議長の要請に応じて、または状況がそのような介入を正当化するときに、これらの決定を行うのを支援する権限と責任があります。
The Chair's responsibility encompasses at least the following:
議長の責任には、少なくとも以下が含まれます。
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. The Chair is also responsible to ensure that the working group operates in an open and fair manner. 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. Sometimes, they also are part of the design team, described below.
議長は、ワーキンググループが前進し、マイルストーンを満たすことを保証する最終的な責任を負います。議長はまた、ワーキンググループがオープンで公正な方法で運営されることを保証する責任があります。一部のワーキンググループでは、これは、議長に管理関連のすべての活動を実行させることによって達成できます。他のワーキンググループ、特に参加者が多い、または意見が分かれているグループでは、プロセスや秘書機能を他の参加者に割り当てると役立ちます。プロセス管理は、その内容ではなく、作業グループの相互作用のスタイルに厳密に関係しています。公平性を確保し、冗長性を検出します。秘書機能には、ドキュメントの編集が含まれます。ワーキンググループが、Specification Editorのタスクを1人または2人の参加者に割り当てることは非常に一般的です。以下に説明するように、設計チームの一部である場合もあります。
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 can be structured as true meetings, conducted over the course of several days (to allow participation across the Internet).
議長は、このリストの議論が適切であり、合意に合意するように努める必要があります。議長は、リストの議論が要約され、結果が十分に文書化されていることを確認する必要があります（繰り返しを避けるため）。議長はまた、議題と成果物を使って、組織化されたオンライン「セッション」をスケジュールすることを選択できます。これらは、数日間にわたって実施される真の会議として構成できます（インターネット経由での参加を可能にするため）。
Organize, prepare and chair face-to-face and on-line formal sessions.
対面およびオンラインの正式なセッションを企画、準備、議長を務めます。
Plan WG Sessions
WGセッションの計画
The Chair must plan and announce all WG sessions well in advance (see section 3.1).
議長は、事前にすべてのWGセッションを計画して発表する必要があります（セクション3.1を参照）。
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 section 3.1).
議長および/または書記は、セッションの議事録が取られ、出席者リストが回覧されていることを確認する必要があります（セクション3.1を参照）。
Immediately after a session, the WG Chair MUST provide the Area Director with a very short report (approximately one paragraph, via email) on the session.
セッションの直後に、WG議長は、エリアディレクターにセッションに関する非常に短いレポート（電子メールで約1段落）を提供する必要があります。
Distribute the workload
ワークロードを分散する
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 must make sure that authors of WG documents incorporate changes as agreed to by the WG (see section 6.3).
ワーキンググループはドキュメントを作成し、ドキュメントには作成者が必要です。議長は、WG文書の作成者がWGが合意した変更を組み込むことを確認する必要があります（セクション6.3を参照）。
Document publication
文書公開
The Chair and/or Document Editor will work with the RFC Editor to ensure document conformance with RFC publication requirements [5] 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公開要件[5]へのドキュメントの適合を確保し、RFCエディターによって提案された編集上の変更を調整します。特に問題になるのは、すべての参加者が同じバージョンのドキュメントから同時に作業していることです。
Document implementations
ドキュメントの実装
Under the procedures described in [1], the Chair is responsible for documenting the specific implementations which qualify the specification for Draft or Internet Standard status along with documentation about testing of the interoperation of these implementations.
[1]で説明されている手順の下で、議長は、ドラフトまたはインターネット標準のステータスの仕様に適合する特定の実装と、これらの実装の相互運用のテストに関する文書化を文書化する責任があります。
Taking minutes and editing working group documents often is performed by a specifically-designated participant or set of participants. In this role, the Secretary's job is to record WG decisions, rather than to perform basic specification.
議事録を取り、作業グループのドキュメントを編集することは、多くの場合、特別に指定された参加者または一連の参加者によって実行されます。この役割での事務局長の仕事は、基本的な仕様を実行することではなく、WGの決定を記録することです。
Most IETF working groups focus their efforts on a document, or set of documents, that capture the results of the group's work. A working group generally designates a person or persons to serve as the Editor for a particular document. The Document Editor is responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the working group.
ほとんどのIETFワーキンググループは、グループの作業の結果をキャプチャするドキュメントまたはドキュメントセットに重点を置いています。ワーキンググループは一般に、特定のドキュメントの編集者となる人物を指定します。ドキュメントエディターは、ドキュメントの内容がワーキンググループによって行われた決定を正確に反映することを保証する責任があります。
As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed.
一般的な慣例として、ワーキンググループの議長とドキュメントエディターのポジションは、結果として生じるドキュメントがワーキンググループのコンセンサスを正確に反映し、すべてのプロセスに従っていることを保証するために、さまざまな個人によって埋められます。
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人の参加者に割り当てると役立ちます。彼らの仕事は、参加者の相互作用の内容ではなく、性質を監督することです。つまり、直接技術的な貢献をするのではなく、ディスカッションのスタイルとアジェンダのスケジュールに参加します。
It is often useful, and perhaps inevitable, for a sub-group of a working group to develop a proposal to solve a particular problem. Such a sub-group is called a design team. In order for a design team to remain small and agile, it is acceptable to have closed membership and private meetings. Design teams may range from an informal chat between people in a hallway to a formal set of expert volunteers that the WG chair or AD appoints to attack a controversial problem. The output of a design team is always subject to approval, rejection or modification by the WG as a whole.
ワーキンググループのサブグループが特定の問題を解決するための提案を作成することは、しばしば有用であり、おそらく避けられません。このようなサブグループは、設計チームと呼ばれます。設計チームが小規模で機敏なままであるためには、メンバーシップと非公開の会議を閉じることが許容されます。設計チームは、廊下にいる人々の間の非公式なチャットから、議論の多い問題を攻撃するためにWG議長またはADが指定する一連の正式なエキスパートボランティアまでさまざまです。設計チームの出力は、常に全体として、WGによる承認、却下、または変更の対象となります。
At the discretion of the Area Director, a Consultant may be assigned to a working group. Consultants have specific technical background appropriate to the WG and experience in Internet architecture and IETF process.
エリアディレクターの裁量で、コンサルタントをワーキンググループに割り当てることができます。コンサルタントは、WGに適した特定の技術的背景と、インターネットアーキテクチャおよびIETFプロセスの経験を持っています。
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.
エリアディレクターは、IETFの全体的な結果への貢献として、そのエリアのワーキンググループが一貫性のある、調整された、アーキテクチャ的に一貫したタイムリーな出力を生成するようにする責任があります。
All relevant documents to be discussed at a session should be published and available as Internet-Drafts at least two weeks before a session starts. Any document which does not meet this publication deadline can only be discussed in a working group session with the specific approval of the working group chair(s). Since it is important that working group members have adequate time to review all documents, granting such an exception should only be done under unusual conditions. The final session agenda should be posted to the working group mailing list at least two weeks before the session and sent at that time to agenda@ietf.org for publication on the IETF web site.
セッションで議論されるすべての関連文書は、セッションが開始する少なくとも2週間前に公開され、インターネットドラフトとして利用可能である必要があります。この公開期限を満たしていないドキュメントは、ワーキンググループの議長の特別な承認を得たワーキンググループセッションでのみ議論できます。ワーキンググループのメンバーがすべてのドキュメントを確認する十分な時間を持つことが重要であるため、このような例外の許可は、異常な状況でのみ行われるべきです。最終的なセッションの議題は、セッションの少なくとも2週間前にワーキンググループのメーリングリストに投稿し、その時点でagenda@ietf.orgに送信してIETF Webサイトで公開する必要があります。
The Internet-Drafts directory is provided to working groups as a resource for posting and disseminating in-process 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.
Internet-Draftsディレクトリは、ワーキンググループドキュメントのインプロセスコピーを投稿および配布するためのリソースとしてワーキンググループに提供されます。このリポジトリは、インターネット上のさまざまな場所で複製されます。ドラフト文書が合理的に安定したらすぐに投稿することをお勧めします。
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@ietf.org
ここで強調されているのは、インターネットドラフトは実用的なドキュメントであり、公式の標準ステータスはまったくないということです。最終的には、標準化に向けた文書に変わったり、見えなくなったりする可能性があります。 Internet-Draftsは、internet-drafts @ ietf.orgに提出されます。
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 on their web site and in the ftp directory; - The I-D filename; and - The expiration date for the I-D.
- 事務局からWebサイトおよびftpディレクトリに提供される、標準的な定型文の最初のテキスト。 -I-Dファイル名。および-I-Dの有効期限。
Complete specification of requirements for an Internet-Draft are found in the file "1id-guidelines.txt" in the Internet-Drafts directory at an Internet Repository site. The organization of the Internet-Drafts directory is found in the file "1id-organization" in the Internet-Drafts directory at an Internet Repository site. This file also contains the rules for naming Internet-Drafts. (See [1] for more information about Internet-Drafts.)
Internet-Draftの要件の完全な仕様は、インターネットリポジトリサイトのInternet-Draftsディレクトリにあるファイル "1id-guidelines.txt"にあります。 Internet-Draftsディレクトリの編成は、インターネットリポジトリサイトのInternet-Draftsディレクトリの「1id-organization」ファイルにあります。このファイルには、インターネットドラフトの命名規則も含まれています。 （インターネットドラフトの詳細については、[1]を参照してください。）
The work of an IETF working group often results in publication of one or more documents, as part of the Request For Comments (RFCs) [1] 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.
IETFワーキンググループの作業により、Request for Comments（RFC）[1]シリーズの一部として、1つ以上のドキュメントが発行されることがよくあります。このシリーズは、インターネットコミュニティのアーカイブ出版物です。ドキュメントは、ワーキンググループの個人、指定された編集者を持つグループ全体、またはIETFに関与していない他のユーザーが作成できます。
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 [4].
注：RFCシリーズは公開メカニズムのみであり、公開はドキュメントのIETFステータスを決定しません。ステータスは、IETFに代わってIESGによって割り当てられる個別の明示的なステータスラベルによって決定されます。言い換えると、読者はすべてのインターネット標準がRFCとして公開されているが、すべてのRFCが標準を指定しているわけではないことを思い出してください[4]。
When a WG decides that a document is ready for publication it may be submitted to the IESG for consideration. In most cases the determination that a WG feels that a document is ready for publication is done by the WG Chair issuing a working group Last-Call. The decision to issue a working group Last-Call is at the discretion of the WG Chair working with the Area Director. A working group Last-Call serves the same purpose within a working group that an IESG Last-Call does in the broader IETF community (see [1]).
WGは、ドキュメントを公開する準備ができていると判断すると、検討のためにIESGに提出できます。ほとんどの場合、WGがドキュメントを公開する準備ができていると感じているという決定は、ワーキンググループLast-Callを発行するWG議長によって行われます。ワーキンググループLast-Callを発行する決定は、エリアディレクターと協力するWG議長の裁量に任されています。ワーキンググループのラストコールは、幅広いIETFコミュニティでIESGラストコールが行うのと同じ目的をワーキンググループ内で果たします（[1]を参照）。
Once that a WG has determined at least rough consensus exists within the WG for the advancement of a document the following must be done:
WGが文書の進歩のために少なくとも大まかなコンセンサスがWG内に存在すると決定したら、次のことを行う必要があります。
- The version of the relevant document exactly as agreed to by the WG MUST be in the Internet-Drafts directory.
- WGが同意したとおりの関連ドキュメントのバージョンは、Internet-Draftsディレクトリにある必要があります。
- The relevant document MUST be formatted according to section 7.3.
- 関連ドキュメントは、セクション7.3に従ってフォーマットする必要があります。
- The WG Chair MUST send email to the relevant Area Director. A copy of the request MUST be also sent to the IESG Secretariat. The mail MUST contain the reference to the document's ID filename, and the action requested. The copy of the message to the IESG Secretariat is to ensure that the request gets recorded by the Secretariat so that they can monitor the progress of the document through the process.
- WG議長は、関連するエリアディレクターにメールを送信する必要があります。リクエストのコピーもIESG事務局に送信する必要があります。メールには、ドキュメントのIDファイル名への参照と、要求されたアクションが含まれている必要があります。 IESG事務局へのメッセージのコピーは、要求が事務局によって確実に記録され、プロセスを通じて文書の進行状況を監視できるようにするためのものです。
Unless returned by the IESG to the WG for further development, progressing of the document is then the responsibility of the IESG. After IESG approval, responsibility for final disposition is the joint responsibility of the RFC Editor, the WG Chair and the Document Editor.
さらなる開発のためにIESGからWGに返されない限り、ドキュメントの進行はIESGの責任です。 IESGの承認後、最終処分の責任は、RFC編集者、WG議長、および文書編集者の共同責任となります。
The IESG reviews all documents submitted for publication as RFCs. Usually minimal IESG review is necessary in the case of a submission from a WG intended as an Informational or Experimental RFC. More extensive review is undertaken in the case of standards-track documents.
IESGは、RFCとして公開するために送信されたすべてのドキュメントをレビューします。情報提供または実験的RFCとして意図されたWGからの提出の場合、通常、最小限のIESGレビューが必要です。標準化過程の文書の場合、より広範なレビューが行われます。
Prior to the IESG beginning their deliberations on standards-track documents, IETF Secretariat will issue a "Last-Call" to the IETF mailing list (see [1]). This Last Call will announce the intention of the IESG to consider 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 should not serve as a more general, in-depth review.
IESGが標準化過程の文書についての審議を始める前に、IETF事務局はIETFメーリングリストに「ラストコール」を発行します（[1]を参照）。このラストコールは、このドキュメントを検討するというIESGの意図を発表し、2週間以内にIETFからの最終的なコメントを求めます。ラストコールは、インターネットコミュニティとの簡単な最終チェックを意図したものであり、重要な懸念事項を見逃したり誤解したりしていないことを確認することが重要です。 Last-Callは、より一般的で詳細なレビューとしては使用できません。
The IESG review takes into account responses to the Last-Call and will lead to one of these possible conclusions: 1. The document is accepted as is for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor.
IESGレビューでは、ラストコールへの応答が考慮され、次のいずれかの結論が導き出されます。1.要求されたステータスについて、ドキュメントはそのまま受け入れられます。この事実は、IETF事務局によってIETFメーリングリストとRFCエディタに発表されます。
2. The document is accepted as-is but not for the status requested. This fact will be announced by the IETF Secretariat to the IETF mailing list and to the RFC Editor (see [1] for more details).
2. ドキュメントは現状のまま受け入れられますが、要求されたステータスは受け入れられません。この事実は、IETF事務局によってIETFメーリングリストとRFC編集者に発表されます（詳細については、[1]を参照してください）。
3. Changes regarding content are suggested to the author(s)/WG. Suggestions from the IESG must be clear and direct, so as to facilitate working group and author correction of the specification. If the author(s)/WG can explain to the satisfaction of the IESG why the changes are not necessary, the document will be accepted for publication as under point 1, above. If the changes are made the revised document may be resubmitted for IESG review.
3. コンテンツに関する変更は、作成者/ WGに提案されます。 IESGからの提案は、仕様のワーキンググループおよび作成者による修正を容易にするために、明確かつ直接的でなければなりません。著者/ WGがIESGに満足して、変更が必要ない理由を説明できる場合、ドキュメントは上記のポイント1に基づいて公開のために受け入れられます。変更が加えられた場合、改訂された文書はIESGレビューのために再提出される場合があります。
4. Changes are suggested by the IESG and a change in status is recommended. The process described above for 3 and 2 are followed in that order.
4. 変更はIESGによって提案され、ステータスの変更が推奨されます。上記の3と2のプロセスは、この順序で行われます。
5. The document is rejected. Any document rejection will be accompanied by specific and thorough arguments from the IESG. Although the IETF and working group process is structured such that this alternative is not likely to arise for documents coming from a working group, the IESG has the right and responsibility to reject documents that the IESG feels are fatally flawed in some way.
5. ドキュメントは拒否されました。ドキュメントの拒否には、IESGからの具体的かつ徹底的な議論が伴います。 IETFとワーキンググループのプロセスは、ワーキンググループからのドキュメントに対してこの代替案が発生する可能性が低くなるように構成されていますが、IESGには、何らかの方法でIESGに致命的な欠陥があると思われるドキュメントを拒否する権利と責任があります。
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 this type of complaints is described in [1].
個人または個人のグループが、レビュー治療が不公平であると感じた場合、手続き上の苦情を申し立てる機会があります。このタイプの苦情のメカニズムは、[1]で説明されています。
Documents describing IETF processes, such as this one, do not have an impact on the security of the network infrastructure or of Internet applications.
このようなIETFプロセスを説明するドキュメントは、ネットワークインフラストラクチャまたはインターネットアプリケーションのセキュリティに影響を与えません。
It should be noted that all IETF working groups are required to examine and understand the security implications of any technology they develop. This analysis must be included in any resulting RFCs in a Security Considerations section. Note that merely noting a significant security hole is no longer sufficient. IETF developed technologies should not add insecurity to the environment in which they are run.
すべてのIETFワーキンググループは、開発するテクノロジーのセキュリティへの影響を調査して理解する必要があることに注意してください。この分析は、「セキュリティに関する考慮事項」セクションの結果のRFCに含める必要があります。重要なセキュリティホールを指摘するだけではもはや十分ではないことに注意してください。 IETFが開発したテクノロジーは、それらが実行される環境に不安を与えてはなりません。
This revision of this document relies heavily on the previous version (RFC 1603) which was edited by Erik Huizer and Dave Crocker. It has been reviewed by the Poisson Working Group.
このドキュメントのこのリビジョンは、Erik HuizerとDave Crockerによって編集された以前のバージョン（RFC 1603）に大きく依存しています。ポアソンワーキンググループによってレビューされています。
[1] Bradner, S., Editor, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、編集者、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Hovey, R., and S. Bradner, "The Organizations involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[2] Hovey、R。、およびS. Bradner、「IETF標準プロセスに関与する組織」、BCP 11、RFC 2028、1996年10月。
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 2282, February 1998.
[3] ギャビンJ。、「IABおよびIESGの選択、確認、およびリコールプロセス：指名委員会およびリコール委員会の運営」、BCP 10、RFC 2282、1998年2月。
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards", RFC 1796, April 1995.
[4] Huitema、C.、J。Postel、S。Crocker、「すべてのRFCが標準であるわけではない」、RFC 1796、1995年4月。
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[5] Postel、J。、およびJ. Reynolds、「Instructions to RFC Authors」、RFC 2223、1997年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
Scott Bradner Harvard University 1350 Mass Ave. Cambridge MA 02138 USA
スコットブラッドナーハーバード大学1350 Mass Ave. Cambridge MA 02138 USA
Phone +1 617 495 3864 EMail: sob@harvard.edu Appendix: Sample Working Group Charter
電話+1 617 495 3864 Eメール：sob@harvard.edu付録：サンプルワーキンググループチャーター
Working Group Name: IP Telephony (iptel)
ワーキンググループ名：IPテレフォニー（iptel）
IETF Area: Transport Area
IETFエリア：トランスポートエリア
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Responsible Area Director:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/siptel
Description of Working Group:
ワーキンググループの説明：
Before Internet telephony can become a widely deployed service, a number of protocols must be deployed. These include signaling and capabilities exchange, but also include a number of "peripheral" protocols for providing related services.
インターネットテレフォニーが広く展開されるサービスになる前に、いくつかのプロトコルを展開する必要があります。これらには、シグナリングと機能交換が含まれますが、関連サービスを提供するためのいくつかの「周辺」プロトコルも含まれます。
The primary purpose of this working group is to develop two such supportive protocols and a frameword document. They are:
このワーキンググループの主な目的は、このような2つの支援プロトコルとフレームワードドキュメントを開発することです。彼らです：
1. Call Processing Syntax. When a call is setup between two endpoints, the signaling will generally pass through several servers (such as an H.323 gatekeeper) which are responsible for forwarding, redirecting, or proxying the signaling messages. For example, a user may make a call to j.doe@bigcompany.com. The signaling message to initiate the call will arrive at some server at bigcompany. This server can inform the caller that the callee is busy, forward the call initiation request to another server closer to the user, or drop the call completely (among other possibilities). It is very desirable to allow the callee to provide input to this process, guiding the server in its decision on how to act. This can enable a wide variety of advanced personal mobility and call agent services.
1. 呼処理構文。 2つのエンドポイント間でコールがセットアップされると、シグナリングは通常、シグナリングメッセージの転送、リダイレクト、またはプロキシを担当する複数のサーバー（H.323ゲートキーパーなど）を通過します。たとえば、ユーザーがj.doe@bigcompany.comを呼び出す場合があります。通話を開始するためのシグナリングメッセージは、bigcompanyのサーバーに到着します。このサーバーは、呼び出し先にビジーであることを呼び出し元に通知したり、呼び出し開始要求をユーザーに近い別のサーバーに転送したり、（他の可能性の中で）呼び出しを完全にドロップしたりできます。呼び出し先がこのプロセスへの入力を提供できるようにして、サーバーがどのように行動するかを決定できるようにすることが非常に望ましいです。これにより、さまざまな高度なパーソナルモビリティとコールエージェントサービスが可能になります。
Such preferences can be expressed in a call processing syntax, which can be authored by the user (or generated automatically by some tool), and then uploaded to the server. The group will develop this syntax, and specify means of securely transporting and extending it. The result will be a single standards track RFC.
このような設定は、ユーザーが作成（またはツールによって自動的に生成）できるコール処理構文で表現され、サーバーにアップロードされます。グループはこの構文を開発し、それを安全に転送および拡張する方法を指定します。結果は、単一の標準トラックRFCになります。
2. In addition, the group will write a service model document, which describes the services that are enabled by the call processing syntax, and discusses how the syntax can be used. This document will result in a single RFC.
2. さらに、グループは、呼処理構文によって有効になるサービスを説明し、構文の使用方法を説明するサービスモデルドキュメントを作成します。このドキュメントは単一のRFCになります。
3. Gateway Attribute Distribution Protocol. When making a call between an IP host and a PSTN user, a telephony gateway must be used. The selection of such gateways can be based on many criteria, including client expressed preferences, service provider preferences, and availability of gateways, in addition to destination telephone number. Since gateways outside of the hosts' administrative domain might be used, a protocol is required to allow gateways in remote domains to distribute their attributes (such as PSTN connectivity, supported codecs, etc.) to entities in other domains which must make a selection of a gateway. The protocol must allow for scalable, bandwidth efficient, and very secure transmission of these attributes. The group will investigate and design a protocol for this purpose, generate an Internet Draft, and advance it to RFC as appropriate.
3. ゲートウェイ属性配布プロトコル。 IPホストとPSTNユーザーの間で電話をかけるときは、テレフォニーゲートウェイを使用する必要があります。このようなゲートウェイの選択は、宛先の電話番号に加えて、クライアントが表す設定、サービスプロバイダーの設定、ゲートウェイの可用性など、多くの基準に基づくことができます。ホストの管理ドメイン外のゲートウェイが使用される可能性があるため、リモートドメインのゲートウェイが属性（PSTN接続、サポートされているコーデックなど）を他のドメインのエンティティに配布して、選択を行う必要があるプロトコルが必要です。ゲートウェイ。プロトコルは、これらの属性のスケーラブルで帯域幅効率がよく、非常に安全な伝送を可能にする必要があります。グループは、この目的のためのプロトコルを調査および設計し、インターネットドラフトを生成し、必要に応じてRFCに進めます。
Goals and Milestones:
目標とマイルストーン：
May 98 Issue first Internet-Draft on service framework Jul 98 Submit framework ID to IESG for publication as an RFC. Aug 98 Issue first Internet-Draft on Call Processing Syntax Oct 98 Submit Call processing syntax to IESG for consideration as a Proposed Standard. Dec 98 Achieve consensus on basics of gateway attribute distribution protocol Jan 99 Submit Gateway Attribute Distribution protocol to IESG for consideration as a RFC (info, exp, stds track TB
98年5月サービスフレームワークに関する最初のインターネットドラフトを発行98年7月RFCとして公開するためにフレームワークIDをIESGに送信する。 98年8月呼処理構文に関する最初のインターネットドラフトを発行98年10月提案された標準として検討するために、呼処理構文をIESGに提出します。 12月98日ゲートウェイ属性配布プロトコルの基本についてコンセンサスを得る1月99日RFCとして検討するために、ゲートウェイ属性配布プロトコルをIESGに提出する（info、exp、stds track TB
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。