RFC2418 日本語訳
2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT=62857 bytes) (Obsoletes RFC1603) (Updated by RFC3934) (Also BCP0025) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bradner Request for Comments: 2418 Editor Obsoletes: 1603 Harvard University BCP: 25 September 1998 Category: Best Current Practice
コメントを求めるワーキンググループS.ブラドナーの要求をネットワークでつないでください: 2418年のエディタは以下を時代遅れにします。 1603ハーバード大学BCP: 1998年9月25日のカテゴリ: 最も良い現在の習慣
IETF Working Group
Guidelines and Procedures
IETFワーキンググループガイドラインと手順
Status of this Memo
この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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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)には、インターネットStandardsとして意図する仕様を開発して、再検討することへの責任があります。 IETF活動はワーキンググループ(WGs)に組織化されます。 このドキュメントはIETFワーキンググループの構成と操作のためのガイドラインと手順について説明します。 また、それはIETF関係者WGと、インターネットEngineering Steering Group(IESG)とIETF関係者の基本任務との正式な関係について説明します、WG Chairs、WG関係者、およびIETF Areaディレクターを含んでいて。
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
要約… 1 1. 序論… 2 1.1. IETFは標準化にアプローチします… 4 1.2. 作業部会の中の役割… 4 2. ワーキンググループ構成… 4 2.1. 構成の評価基準… 4 2.2. チャーターします。 6 2.3. 憲章レビューと承認… 8 2.4. 羽(BOF)の鳥… 9 3. ワーキンググループ操作… 10 3.1. セッション計画… 11 3.2. セッション開催地… 11 3.3. セッション管理… 13 3.4. 主張と上告… 15
Bradner Best Current Practice [Page 1] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[1ページ]RFC2418ワーキンググループガイドライン1998年9月
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
4. ワーキンググループ終了… 15 5. 作業部会をRecharteringします… 15 6. 役割を配置してください… 16 6.1. WG議長… 16 6.2. WG長官… 18 6.3. エディタを記録してください… 18 6.4. WGまとめ役… 18 6.5. チームを設計してください… 19 6.6. 作業部会のコンサルタント… 19 6.7. 領域のディレクター… 19 7. ワーキンググループドキュメント… 19 7.1. セッションドキュメント… 19 7.2. インターネット草稿(I-D)… 19 7.3. コメント(RFC)のために、要求します。 20 7.4. ワーキンググループの最後の呼び出し… 20 7.5. ドキュメントの提出… 21 8. ドキュメントのレビュー… 21 9. セキュリティ問題… 22 10. 承認… 23 11. 参照… 23 12. エディタのアドレス… 23付録: ワーキンググループ憲章を抽出してください… 24 完全な著作権宣言文… 26
1. Introduction
1. 序論
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.
インターネット(自治の、そして、インタコネクトされたネットワークの緩く組織化された国際協力)は、インターネットStandardsによって定義されたプロトコルと手順を開くために自発的の固守でホスト間通信を支持します。 また、多くの孤立している相互接続ネットワークがあります。(世界的なインターネットに関連づけられませんが、相互接続ネットワークはインターネットStandardsを使用します)。 インターネットStandardsはインターネット・エンジニアリング・タスク・フォース(IETF)で開発されます。 このドキュメントはIETFワーキンググループのためにガイドラインと手順を定義します。 IETFのインターネットStandards Processは[1]で定義されます。 IETF Standards Processにかかわる組織は特定の個人の役割のように[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 Working Groupsのリストに関してIETFウェブページを見てください-- http://www.ietf.org ) ワーキンググループは、狭い焦点を持っている傾向があります、そして、寿命は特定のセットのタスクの完成でバウンドしました、例外がありますが。
Bradner Best Current Practice [Page 2] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[2ページ]RFC2418ワーキンググループガイドライン1998年9月
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人のAreaディレクター(ADs)によって管理されます。 現在、IETFにもかかわらず、数の変化には8つの領域が時々あります。 (現在の領域のリスト、各領域へのAreaディレクター、およびワーキンググループが各領域に割り当てられるリストに関してIETFウェブページを見てください。)
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.
多くの領域で、Areaディレクターは顧問団か管理職を形成しました。 これらはIETFの経験豊富なメンバーと領域によって代理をされた技術的な共同体を包括します。 各グループのための役割の種名と詳細は領域から領域まで異なりますが、第一の意図はこれらのグループがAreaディレクターを補助するということです、例えば、仕様のレビューがその領域で製作されている状態で。
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議長と共にインターネットEngineering Steering Group(IESG)を包括します。 IETF専務はIESGの元のofficio関係者です、IAB議長と指定されたインターネット・アーキテクチャ委員会(IAB)の連絡係のように。 IESGはIETF Standardsを承認して、他の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
このドキュメントはIETFでのワーキンググループの構成と操作のための手順とガイドラインを定義します。 それはIETFの中の他のボディーとワーキンググループの関係を定義します。 また、ワーキンググループの操作に関するワーキンググループChairsとAreaディレクターの義務は定義されます。 “SHALL"、いつが本書では“MUST"、「必須NOT」が「必要である」というキーワードを使用したか、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように解釈されることであるべきですか? RFC2119は、標準化過程ドキュメントの意図をできるだけ明確にするのを助けるためにこれらのキーワードの使用を定義します。 同じキーワードはこれで使用されます。
Bradner Best Current Practice [Page 3] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[3ページ]RFC2418ワーキンググループガイドライン1998年9月
document to help smooth WG operation and reduce the chance for confusion about the processes.
滑らかなWG操作を助けて、混乱のために過程に関して可能性を小さくするために、記録します。
1.1. IETF approach to standardization
1.1. 標準化へのIETFアプローチ
Familiarity with The Internet Standards Process [1] is essential for a complete understanding of the philosophy, procedures and guidelines described in this document.
哲学の完全な理解に、インターネットStandards Process[1]への親しみは不可欠です、と手順とガイドラインは本書では説明しました。
1.2. Roles within a Working Group
1.2. 作業部会の中の役割
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]はワーキンググループの中で個体数の役割について説明します、ワーキンググループいすとドキュメントエディタを含んでいて。 これらの記述は後で本書では広げられます。
2. Working group formation
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ワーキンググループ(WGs)はIETF仕様とガイドラインの開発のための一次機構です。その多くが規格か推薦であることを意図します。 ワーキンググループがAreaディレクターのイニシアチブのときに設立されるかもしれませんか、またはそれは個人か個体群によって開始されるかもしれません。 IETFワーキンググループを創設したがっていただれでも、ワーキンググループが領域で転ぶIETF Areaディレクターの助言と同意を得なければならなくて、このセクションで詳細な正式なステップで続かなければなりません。
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の同意を得て、ワーキンググループのAreaディレクターか、WG議長と、WG関係者か、目的か課題が、「再-特許」の過程でワーキンググループの特許を変更することによって、敷衍されるかもしれません(セクション5を見てください)。
2.1. Criteria for formation
2.1. 構成の評価基準
When determining whether it is appropriate to create a working group, the Area Director(s) and the IESG will consider several issues:
ワーキンググループを創設するのが適切であるかどうか決定するとき、Areaディレクターと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?
- 目標は、妥当な時間枠の中で特定で、合理的に達成可能で、達成可能ですか?
Bradner Best Current Practice [Page 4] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[4ページ]RFC2418ワーキンググループガイドライン1998年9月
- 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.
- ワーキンググループの活動は別のワーキンググループのものに重なりますか? そうだとすれば、それは、ワーキンググループを創設するのがまだ適切であるかもしれませんが、しばしば努力を細分するとしてのAreaディレクターで慎重に利用可能な技術的専門知識を希釈しますこの質問を考えなければならない。
- 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人の人がこれらの役割をすべて扱うことができないのを示します。 管理職の最低4か5人の積極的な参加者がワーキンググループミーティングに出席して、メーリングリストで貢献する最低ものか2ダースの人々に加えて通常必要です。 以下に注意してください。 関心はワーキンググループが単に独身の業者の活動は考えられないほど広くなければなりません。
- 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関係者からの入力の効果が制限されるかもしれないところの試みですか?
Bradner Best Current Practice [Page 5] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[5ページ]RFC2418ワーキンググループガイドライン1998年9月
- 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.
上の評価基準を考えると、その人の最も良い判断を使用して、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(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)からされますが、関連Areaディレクター(s)。 特許は1セットのタスクを実行するワーキンググループと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。 彼らの完成のために時間枠と共に1セットの重大事件を列挙します。
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.
将来の議長、Areaディレクター、およびIETF事務局が特許フォームと内容に満足しているとき、それはワーキンググループを形成する基礎になります。 Areaディレクターが、踏査のBirdsを持っているのをFeather(BOF)ミーティングを要求するかもしれないことに注意してください、承認のためにIESGとIABに特許を提出する前にワーキンググループのためにサポート水準を抵当に入れるために以下で説明されるように。
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.
ワーキンググループ名前Aワーキンググループ名は、かなり描写的である、または身元保証可能であるべきです。 さらに、グループは頭文字語(8人の最大の印刷可能なASCII文字)をIETFディレクトリ、メーリングリスト、および一般のグループが記録する参照と定義するものとします。
Bradner Best Current Practice [Page 6] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[6ページ]RFC2418ワーキンググループガイドライン1998年9月
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.
ワーキンググループが1Chairsを持っているかもしれない議長はグループの行政機能を実行します。 議長のEメールアドレス(es)は含まれているものとします。 一般に、ワーキンググループは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ディレクターの領域とワーキンググループが系列であるIETF領域の名前、名前、および電子メールが演説するAreaディレクター。
Responsible Area Director
The Area Director who acts as the primary IESG contact for the
working group.
責任があるAreaディレクター、第一のIESGがワーキンググループのために連絡するように行動するAreaディレクター。
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:
メーリングリストAn 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かウェブでアクセスできる公共の場でメッセージアーカイブを維持しなければなりません。
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_頭文字語」がワーキンググループ頭文字語であるところ)を含まなければなりません。 それらのアーカイブは ftp://ftp.ietf.org/ietf-mail-archive に位置しています。 丈夫さのために、WGs 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
記述、ワーキンググループでは、グループの焦点と意図は簡潔に詳しく説明されるものとします。 単独でこのセクションを読むことによって、個人は、このグループがそれら自身の仕事に関連しているかどうか決めることができるべきです。 第一節はワーキンググループのために計画されていた問題領域、基礎、目標、およびアプローチ(es)の簡潔な概要をしなければなりません。 ワーキンググループの概観としてこのパラグラフを使用できます。
Bradner Best Current Practice [Page 7] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[7ページ]RFC2418ワーキンググループガイドライン1998年9月
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).
ワーキンググループがチャーターする目標と重大事件は特定の仕事項目のための時刻表を設立しなければなりません。これは時間がたつにつれて再交渉されるかもしれませんが、重大事件と日付のリストはAreaディレクターのワーキンググループ進歩と状態の追跡を容易にします、そして、入力のために瀬戸際を特定する潜在的関係者にとって、それは不可欠です。 重大事件は特定の実績を示していながら資格を得られることができる提出物から成るものとします。 メールしてください。を通してしかし、例えば、「インターネット草稿は終わったこと」がすばらしい、「議論、」 ありません。 月の間、あらゆる3-6に重大事件を指定するのは、容易に進歩を測ることができるように役立っています。 この重大事件リストが定期的にアップデートすると予想されます(セクション5を見てください)。
An example of a WG charter is included as Appendix A.
WG特許に関する例はAppendix Aとして含まれています。
2.3. Charter review & approval
2.3. 憲章レビューと承認
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の過程の歴史に詳しくない技術的に有能な関係者を包括します。 残念ながら、これは悪いデザインに関する良いワーキンググループコンセンサスに通じることができます。 ワーキンググループの努力を容易にするために、Areaディレクターは年上のIETF関係者のランクからConsultantを割り当てるかもしれません。 (コンサルタントはセクション6で説明されます。) Areaディレクターの裁量では、十分なコンサルタントリソースがないとき新しい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
承認されて、ワーキンググループ特許、特許はそうです。そして、かつてのAreaディレクター、(Areaディレクターが、適切であると考えるようなArea Directorate、レビューのために、IABと承認で、IESGによって提出されます。 少なくとも1週間のレビューの期間の後に、公衆が、ワーキンググループの構成が考えられているのに気付いて、提案された特許はIETF発表しているメーリングリストに掲示されます。 また、同時に、提案された特許は「新しい仕事」郵送に掲示されます。
Bradner Best Current Practice [Page 8] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[8ページ]RFC2418ワーキンググループガイドライン1998年9月
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
記載してください。 未定のIETFワーキンググループに関して他の規格組織からの適任の代表に知らせるためにこのメーリングリストを作成してあります。 少なくとも1週間の別のレビュー期間のもつことの後にIESG MAYがそのままな特許を承認して、それは、変更が特許で行われるよう要求するか、またはワーキンググループの特許を承認するのを断るかもしれません。
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発表しているaに発表されます。
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. In addition, 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 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を承認しなければならない関連Areaディレクターに要望書を提出しなければなりません。 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の結果に関するレポートを提供するのに責任があります。 Areaディレクターが承認するなら、BOFは、コピーがある agenda@ietf.org に要求を提出することによって、Areaディレクターに予定されています。 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,
BOFsのための使用可能時間は限られています、そして、BOFsは領域へのADsの裁量で持たれています。 BOFを認可する前に、ADは追加保証を必要とするかもしれません。 例えば
- 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を認可する前に、Areaディレクターは開いているメールリストを設立に要求するかもしれません。 これは枠組み、ボキャブラリー、およびアプローチの初期の交換と共有を可能にします、BOFに費やされた時間をより生産的にするように。
- The Area Director MAY require that a BOF be held, prior to
establishing a working group (see section 2.2).
- Areaディレクターは、ワーキンググループを設立する前にBOFが持たれているのを必要とするかもしれません(セクション2.2を見てください)。
- The Area Director MAY require that there be a draft of the WG
charter prior to holding a BOF.
- AreaディレクターはWGの草稿がBOFを持つ前の特許であったならそこでそれを必要とするかもしれません。
Bradner Best Current Practice [Page 9] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[9ページ]RFC2418ワーキンググループガイドライン1998年9月
- 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.
- Areaディレクターは、提案された技術を説明するインターネット草稿がBOFでの議論の基礎としてそれを使用できるように発表されるまでBOFが持たれていないのを必要とするかもしれません。
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つのIETF PlenaryミーティングにおけるONEスロット)だけ持たれています。 もう一度のAreaディレクターが彼らの裁量でBOFを会わせるかもしれない珍しい状況で。 BOFsが3回会うことが許可されていません。 他のすべてのものが等しい場合、WGsはBOFsの上で集会場が優先することに注意してください。 また、時折、BOFsはワーキンググループの構成について議論すること以外の目的のために持たれているかもしれません。
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の構成を保証するほどありました。
- 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の構成を保証できるくらいの関心がありませんでした。
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". 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
ワーキンググループ活動を組織化するか、または行うとき、鉄則がわずかしかありませんが、成功した1セットのガイドラインと習慣は時間がたつにつれて、発展しました。 これらはここに記載されています。
Bradner Best Current Practice [Page 10] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[10ページ]RFC2418ワーキンググループガイドライン1998年9月
actual choices typically determined by the working group participants and the Chair(s).
ワーキンググループの関係者と議長で通常決定している実際の選択。
3.1. Session planning
3.1. セッション計画
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.
- 議論のための項目。 - 1項目あたり必要なおよそ時間。 そして、--関係者を記録することの明確なしるしは、セッションの前によく準備されるために読む必要があるでしょう。
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 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: minutes@ietf.org
すべてのワーキンググループセッション(IETFミーティングの外に保持されたものを含んでいる)が、数分を利用可能にすることによって、報告されるものとします。 これらの数分はセッションのための議題、どんな決定も作った議論包含のアカウント、および出席者のリストを含むべきです。 セッション議事録が書かれていて、分配されるのを保障するのに作業部会議長は責任があります、実際のタスクが作業部会議長によって任命されただれかによって実行されるかもしれませんが。 議事録は、IETF Proceedingsでの公表、およびIETFディレクトリにおける任命のために印刷可能なASCIIテキストで提出して、以下のことのために送ることでしょう。 minutes@ietf.org
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
各ワーキンググループはメールと表面から表面へのセッションの重大事件を達成するのに、適切なバランスを決定するでしょう。 電子メールは最も広い参加を可能にします。 さしの会談は、しばしばより良い焦点を可能にして、ワーキンググループのコアの中でコンセンサスに達するには、したがって、より効率的である場合があります。
Bradner Best Current Practice [Page 11] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[11ページ]RFC2418ワーキンググループガイドライン1998年9月
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ミーティングの最初の発表がIETF事務局によってWG-いすリストにされるとすぐに、IETFミーティングにおけるセッション、IETF Meetings If WG必要性議長は時間帯に申し込まなければなりません。 セッション時間がIETFミーティングで不十分なリソースであるので、早く要求を置くと、スケジュールコーディネートは同じセットに専門家を要求するWGsのために容易にされるでしょう。
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:
アドレス agenda@ietf.org でIETFミーティングにおけるWGセッションのためのアプリケーションをIETF事務局にしなければなりません。 Areaディレクターの中にはそれらの領域で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セッションに出席する人々の概算数。 - 同じ時間帯のために予定されるべきでないWGsは関係づけました。 そして、--任意に、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.
以下に注意してください。 公開討論と貢献はワーキンググループ成功に不可欠ですが、議長は前進の進歩を確実にするのに責任があります。 進歩を遂げる目的のためのIETFワーキンググループセッションのときにWGに許容できるとき、議長は制限された参加(しかし、制限された出席でない!)を求めるかもしれません。 または、次に、作業部会議長にはどんな用意ができていていない個人かそうでなければ、不適切な素材をカバーするのにも床を与えるのを拒否する権威がある、だれ、議長に関する意見では、WGの過程を混乱させるのは、そうであるか。 個人が破壊的な行動に固執するなら、議長はAreaディレクターと相談するべきです。
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.
オンラインItは面と向かっているセッションと同じ方法でメール交換を行うためにかなり役に立つ場合があります、発行されたスケジュールと議題で、継続している総括とコンセンサス世論調査と同様に。
Bradner Best Current Practice [Page 12] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[12ページ]RFC2418ワーキンググループガイドライン1998年9月
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の進歩を混乱させるメーリングリストで振舞いに従事するかもしれません。 これらの場合では、議長は、開いているメーリングリストでというよりむしろ直接怒っている個人とのコミュニケーションで振舞いに水をさしているのを試みるべきです。 振舞いが持続しているなら、議長は結局のところ、Areaディレクターにかかわらなければなりません。 切り札と明白な警告の後に、Areaディレクターは、IESGの承認をもってメーリングリスト維持装置がメーリングリストに掲示する怒っている個人の能力を妨げるよう要求するかもしれません。 (メーリングリストソフトウェアがこのタイプの操作を可能にするなら。) これが完了していても、メッセージが掲示した受信からリストまで個人を防いではいけません。 メーリングリストコントロールの他の方法を考えられるかもしれませんが、ADとIESGは承認しなければなりません。
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 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が同意する(もちろん荒いコンセンサスで)いかなる他の手段でも決定できます。 「荒いコンセンサス」と99%があぶれ者より良いのでワーキンググループの51%が資格を得ないことに注意してください。 荒いコンセンサスに達したかどうか決定するのは、議長次第です。
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
表面への表面ミーティングの間に達しているコンセンサスがメーリングリストで確かめられている場合では、ミーティングにはいて、協定を表した人々を考慮に入れなければなりません。 100人の人がミーティングとほんの数人の人々にいたなら
Bradner Best Current Practice [Page 13] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[13ページ]RFC2418ワーキンググループガイドライン1998年9月
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.
メーリングリストに関して、ミーティングのコンセンサスと意見を異にしてください、そして、次に、コンセンサスは確かめられるのが見られるべきです。 メーリングリスト読者はリストで上げられるどんな反論も理解して、十分な時間を検証の過程と考えさせられるべきであることに注意してください。 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.
もう片方のケースは議論が完全なメーリングリストで行われたところです。 コンセンサスのレベルの決断はメーリングリストに申し込まれたほとんどの人々がリストで活発に議論に参加しないのでこの場合するのは、より困難であるかもしれません。 ワーキンググループの裁量への左がどうコンセンサスのレベルを評価するかをまとめるということです。 使用される最も多くの共通方法がワーキンググループいすがその人が大多数の見解であると信じていることを述べることであり. 同時に要求は述べられた結論に関するリストからのコメントです。
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 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;
入力が新しく、既に決心していて、それだけが感じられるということである話題に関係する既存の決定への小さい方の輸入の未成年者。
Bradner Best Current Practice [Page 14] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[14ページ]RFC2418ワーキンググループガイドライン1998年9月
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
3.4. 主張と上告
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、議長、AreaディレクターまたはIESG動作のレビューを要求して、上告を行うための正式手順はインターネットStandards Process[1]に記録されます。
4. Working Group Termination
4. ワーキンググループ終了
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がProposedかDraft Standardを生産すると、WGは解散するより頻繁にむしろ眠るようになるでしょう。(すなわち、WGはもうホルマール活性を行わないでしょうが、メーリングリストはDraft StandardとStandard状態に動くとき仕事を見直すために利用可能なままで残るでしょう。)
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:
Areaディレクター、ワーキンググループが特許に概説された仕事を終了できないのが何らかのポイントで明白になるか、または基づいた仮定が議論か経験で変更されたなら、ワーキンググループとの相談で変更できました:
1. Recharter to refocus its tasks, 2. Choose new Chair(s), or 3. Disband.
1. タスク、2の焦点を再び合わせる再認可。 新しい議長、または3を選んでください。 解散してください。
If the working group disagrees with the Area Director's choice, it may appeal to the IESG (see section 3.4).
ワーキンググループがAreaディレクターの選択と意見を異にするなら、それはIESGの好みに合うかもしれません(セクション3.4を見てください)。
5. Rechartering a Working Group
5. 作業部会をRecharteringします。
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.
アップデートされた重大事件を必要であるようにAreaディレクターとIESGに再交渉して、次に、IESG事務局に提出します: iesg-secretary@ietf.org 。
Bradner Best Current Practice [Page 15] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[15ページ]RFC2418ワーキンググループガイドライン1998年9月
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.
ワーキンググループをRecharteringすると(重大事件を改訂するのを除いて)、初期の特許がするのと同じ手順は従われます(セクション2を見てください)。 承認のためにIESGとIABに改訂された特許を提出しなければなりません。 IESGが初期の特許でそのままな新しい特許を承認するとき、変更が新しい特許で行われるよう要求するかもしれませんか(作業部会に古い特許を使用し続けさせるのを含んでいて)、またはそれは、「再-特許」のワーキンググループを承認するのを断るかもしれません。 後者の場合では、ワーキンググループは解散されます。
6. Staff Roles
6. スタッフの役割
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.
ワーキンググループはかなりの注意と食べることを必要とします。 一般的な参加に加えて、うまくいっているワーキンググループは特定の機能的役割をいっぱいにしている関係者の努力の利益を得ます。 AreaディレクターはWG議長、および作業部会Consultantの役割を実行している特定の人々に同意しなければなりません、そして、それらはAreaディレクターの裁量に役立ちます。
6.1. WG Chair
6.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.
作業部会議長は、公正で開いている過程で前進の進歩をするのに関係があって、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
議長には、ワーキンググループが前進の進歩を遂げて、重大事件を満たすのを確実にすることへの最終責任があります。 また、ワーキンググループが開いていて公正な方法で作動するのを保証するのにおいて議長も責任があります。 いくつかのワーキンググループに関しては、議長にすべての管理関連の活動を実行させることによって、これを達成できます。 他のワーキンググループ(特に大きいか分析的な参加があるそれら)では、過程、そして/または、業務代理機能を他の関係者に割り当てるのは役立っています。 工程管理は厳密に内容ではなく、ワーキンググループ相互作用のスタイルに関係します。 それは、公正を確実にして、冗長を検出します。 業務代理機能はドキュメント編集を成就します。 働きに、それは全く一般的です。
Bradner Best Current Practice [Page 16] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[16ページ]RFC2418ワーキンググループガイドライン1998年9月
group to assign the task of specification Editor to one or two
participants. Sometimes, they also are part of the design team,
described below.
分類して、仕様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つのパラグラフ)をAreaディレクターに提供しなければなりません。
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を見てください)。
Bradner Best Current Practice [Page 17] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[17ページ]RFC2418ワーキンググループガイドライン1998年9月
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.
議長、そして/または、Document Editorは、RFC公表要件[5]でドキュメント順応を確実にして、RFC Editorによって勧められたどんな編集の変化も調整するためにRFC Editorと共に働くでしょう。 特別の関心はすべての関係者が同時にドキュメントの同じバージョンから働いているということです。
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]で説明された手順の下では、議長はこれらの実現のinteroperationをテストすることに関するDraftのために仕様に資格を与える特定の実現を記録するか、ドキュメンテーションに伴うインターネットStandard状態に責任があります。
6.2. WG Secretary
6.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 Secretary's job is to record WG decisions, rather than to perform basic specification.
何分もかかって、ワーキンググループドキュメントを編集するのはしばしば明確に指定された関係者かセットの関係者によって実行されます。 この役割に、長官の仕事は基本の仕様を実行するというよりむしろWG決定を記録することです。
6.3. Document Editor
6.3. ドキュメントエディタ
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ワーキンググループがグループの仕事の結果を得るドキュメントにおける彼らの努力、またはドキュメントのセットの焦点を合わせます。 一般に、ワーキンググループは、特定のドキュメントのためのEditorとして機能するように人か人々を任命します。 ドキュメントの中身が正確にワーキンググループによってされた決定を反映するのを確実にするのにDocument Editorは責任があります。
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.
一般診療として、作業部会議長とDocument Editorの欠員は、結果として起こるドキュメントが正確にワーキンググループのコンセンサスを反映して、すべての過程が従われているのを確実にするのを助けるために異なった個人によって補充されます。
6.4. WG Facilitator
6.4. 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人の関係者に割り当てるのはしばしば役立っています。 彼らの仕事は関与している相互作用の内容よりむしろ自然を監督することです。 すなわち、彼らはダイレクト技術的な貢献自体をするよりむしろ議論のスタイルと、そして、議題のスケジュールに出席します。
Bradner Best Current Practice [Page 18] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[18ページ]RFC2418ワーキンググループガイドライン1998年9月
6.5. Design teams
6.5. デザインチーム
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による承認、拒絶または変更を必要としています。
6.6. Working Group Consultant
6.6. 作業部会のコンサルタント
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.
Areaディレクターの裁量では、Consultantはワーキンググループに配属されるかもしれません。 コンサルタントは特定の技術的なバックグラウンドをインターネット構造とIETFの過程のWGと経験に適切にします。
6.7. Area Director
6.7. 領域のディレクター
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の総合的な結果への貢献として一貫性を持っていて、連携していて、建築上一貫してタイムリーな出力を起こすのを確実にするのに領域のディレクターは責任があります。
7. Working Group Documents
7. ワーキンググループドキュメント
7.1. Session documents
7.1. セッションドキュメント
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週間前にワーキンググループメーリングリストに掲示して、その時、公表のためにIETFウェブサイトで agenda@ietf.org に送るべきです。
7.2. Internet-Drafts (I-D)
7.2. インターネット草稿(I-D)
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
製造過程のコピーのワーキンググループドキュメントを掲示して、広めるためのリソースとしてインターネット草稿ディレクトリをワーキンググループに提供します。 この倉庫はインターネットの周りの様々な位置で模写されます。 奨励されて、掲示されていて、それがドキュメントを作成するということです。
Bradner Best Current Practice [Page 19] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[19ページ]RFC2418ワーキンググループガイドライン1998年9月
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@ietf.org
ここで、インターネット草稿が働くドキュメントであり、公式の規格状態を全く持っていないと強調されます。結局、標準化過程文書に変わるかもしれませんか、またはそれらは視界から没するかもしれません。 以下のことのためにインターネット草稿を提出します。 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.
- それらのウェブサイトの上と、そして、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.)
インターネット草稿のための要件の完全な仕様はインターネットRepositoryサイトのインターネット草稿ディレクトリのファイル"1id-guidelines.txt"で見つけられます。 インターネット草稿ディレクトリの組織はインターネットRepositoryサイトのインターネット草稿ディレクトリの「1id-組織」というファイルで見つけられます。 また、このファイルはインターネット草稿を命名するための規則を含んでいます。 (インターネット草稿に関する詳しい情報のための[1]を見てください。)
7.3. Request For Comments (RFC)
7.3. コメントを求める要求(RFC)
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ワーキンググループの仕事はしばしば1通以上のドキュメントの公表をもたらします、Request For Comments(RFCs)[1]シリーズの一部として。 このシリーズはインターネットコミュニティのための記録保管所の公表記録です。 個人はワーキンググループでドキュメントを書くことができます、指定されたEditor、または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によって割り当てられた別々の、そして、明白な状態ラベルを通して決定します。 言い換えれば、読者はすべてのRFCsではなく、RFCsが規格[4]を指定するときすべてのインターネットStandardsが発行されるのを思い出させられています。
7.4. Working Group Last-Call
7.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
WGが、ドキュメントが公表の準備ができていると決めると、考慮のためにIESGにそれを提出するかもしれません。 多くの場合、Lastが電話をするワーキンググループを発行するWG議長はWGが公表の準備ができているとそのaドキュメントと感じる決断を完了しています。 Areaディレクターと共に働いているWG議長の裁量にはワーキンググループLast-呼び出しを発行するという決定があります。 ワーキンググループLast-呼び出しはワーキンググループの中の同じ目的にそれに役立ちます。
Bradner Best Current Practice [Page 20] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[20ページ]RFC2418ワーキンググループガイドライン1998年9月
an IESG Last-Call does in the broader IETF community (see [1]).
より広いIETF共同体にIESG Last-呼び出しします。([1])を見てください。
7.5. Submission of documents
7.5. ドキュメントの提出
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:
そのa WGが、少なくとも荒いコンセンサスが以下がそうしなければならないドキュメントの進歩のためのWGの中に存在することをいったん決定したと、してください:
- The version of the relevant document exactly as agreed to by the WG
MUST be in the Internet-Drafts directory.
- インターネット草稿ディレクトリのWG MUSTによるであるちょうど同意されるとしての関連ドキュメントのバージョン。
- 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議長は関連Areaディレクターにメールを送らなければなりません。 また、要求のコピーを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.
さらなる開発のためのWGへのIESGによって返されない場合、そして、ドキュメントの進歩はIESGの責任です。 IESG承認の後に、最終的な気質への責任はRFC Editor、WG議長、およびDocument Editorの共同責任です。
8. Review of documents
8. ドキュメントのレビュー
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は公表のためにRFCsとして提出されたすべてのドキュメントを再検討します。 通常最小量のIESGレビューがInformationalかExperimental RFCとして意図するWGからの服従の場合で必要です。 より大量のレビューは標準化過程文書の場合で引き受けられます。
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])を見てください。 このLast CallはIESGがドキュメントを考えるという意志を発表するでしょう、そして、それは2週間の期間以内にIETFから最終的なコメントに請求するでしょう。 インターネットコミュニティとの簡潔で、最終的なチェックとしてLast-呼び出しが、どんな重要な関心も逃されてもいませんし、誤解されてもいないのを確実にすることを意図することに注意するのは重要です。 Last-呼び出しは、より一般的で、徹底的なレビューとして機能するべきではありません。
The IESG review takes into account responses to the Last-Call and will lead to one of these possible conclusions:
IESGレビューは、Last-呼び出しへの応答を考慮に入れて、これらの可能な結論の1つに通じるでしょう:
Bradner Best Current Practice [Page 21] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[21ページ]RFC2418ワーキンググループガイドライン1998年9月
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.
1. 要求された状態にそのままであるとドキュメントを受け入れます。 この事実はIETFメーリングリストと、そして、RFC EditorへのIETF事務局によって発表されるでしょう。
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メーリングリストと、そして、RFC EditorへのIETF事務局によって発表されるでしょう(その他の詳細のための[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. 内容に関する変化は作者(s)/WGに示されます。 IESGからの提案は、明確であって、ダイレクトであるに違いありません、仕様のワーキンググループと作者修正を容易にするために。 作者(s)/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]で説明されます。
9. Security Considerations
9. セキュリティ問題
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ワーキンググループがそれらが開発するどんな技術のセキュリティ含意も調べて、理解するのに必要であることに注意されるべきです。 Security Considerations部のどんな結果として起こるRFCsにもこの分析を含まなければなりません。 単に重要なセキュリティーホールに注意するのがもう十分でないことに注意してください。 IETFは技術を開発しました。それらが走行である環境に不安定を加えるべきではありません。
Bradner Best Current Practice [Page 22] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[22ページ]RFC2418ワーキンググループガイドライン1998年9月
10. Acknowledgments
10. 承認
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.
このドキュメントのこの改正は大いにエリックHuizerとデーヴ・クロッカーによって編集された旧バージョン(RFC1603)を当てにします。 それはポアソン作業部会によって見直されました。
11. References
11. 参照
[1] Bradner, S., Editor, "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[1] ブラドナー、S.、エディタ、「インターネット規格は処理されます--改正3インチ、BCP9、RFC2026、1996年10月。」
[2] Hovey, R., and S. Bradner, "The Organizations involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[2] ハービ、R.とS.ブラドナー、「IETF Standards ProcessにかかわるOrganizations」BCP11、1996年10月のRFC2028。
[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選択、確認、およびリコールは処理します」。 「指名とリコール委員会の操作」、BCP10、RFC2282、1998年2月。
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
RFC 1796, April 1995.
[4]Huitema、C.、J.ポステル、S.クロッカー、「すべてのRFCsがStandardsであるというわけではありません」、RFC1796、1995年4月。
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[5] ポステル、J.、およびJ.レイノルズ、「指示、RFCが書く、」、RFC2223、10月1997日
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12. Editor's Address
12. エディタのアドレス
Scott Bradner Harvard University 1350 Mass Ave. Cambridge MA 02138 USA
スコットブラドナーハーバード大学1350はAveを一かたまりにします。 ケンブリッジMA02138米国
Phone +1 617 495 3864 EMail: sob@harvard.edu
+1に、3864がメールする617 495に電話をしてください: sob@harvard.edu
Bradner Best Current Practice [Page 23] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[23ページ]RFC2418ワーキンググループガイドライン1998年9月
Appendix: Sample Working Group Charter
付録: サンプルワーキンググループ憲章
Working Group Name:
IP Telephony (iptel)
ワーキンググループ名: IP電話(iptel)
IETF Area:
Transport Area
IETF領域: 輸送領域
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
議長(s): ジョナサン Rosenberg <jdrosen@bell-labs.com 、gt。
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
領域のディレクターを輸送してください: スコット Bradner <sob@harvard.edu 、gt;、アリン Romanow <allyn@mci.net 、gt。
Responsible Area Director:
Allyn Romanow <allyn@mci.net>
責任がある領域のディレクター: アリン Romanow <allyn@mci.net 、gt。
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
メーリングリスト: 議論: 申し込む一般 iptel@lists.research.bell-labs.com : iptel-request@lists.research.bell-labs.com アーカイブ: 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つの支持しているプロトコルとframewordドキュメントを開発することです。 それらは以下の通りです。
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門番などの)を通り抜けるでしょう、シグナリングメッセージを向け直すか、またはproxyingして。 例えば、ユーザは j.doe@bigcompany.com に電話をかけるかもしれません。 呼び出しを開始するシグナリングメッセージはbigcompanyの何らかのサーバに到着するでしょう。 このサーバは、訪問される人が忙しいことを訪問者に知らせるか、ユーザの、より近くで呼び出し開始要求を別のサーバに転送するか、または呼び出しを完全(他の可能性の中で)に落とすことができます。 訪問される人がこの過程に入力を提供するのを許容するのは非常に望ましいです、どう行動するかに関する決定におけるサーバを誘導して。 これはさまざまな高度な個人的な移動性と呼び出しエージェントサービスを可能にすることができます。
Bradner Best Current Practice [Page 24] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[24ページ]RFC2418ワーキンググループガイドライン1998年9月
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の接続性、支持されたコーデックなどの)をゲートウェイの選択をしなければならない他のドメインの実体に分配するのを許容するのに必要です。 プロトコルはこれらの属性のスケーラブルで、帯域幅効率的で、非常に安全な送信を考慮しなければなりません。 グループは、適宜このためにプロトコルを調査して、設計して、インターネットDraftを発生させて、それを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
5月98日のIssueは最初に、サービス枠組み7月98日のSubmit枠組みでRFCとしての公表のためのIESGへのIDをインターネットで作成します。 Proposed Standardとしての考慮のためのIESGへの8月98日のCall Processing Syntax10月98日のSubmit CallにおけるIssue最初のインターネット草稿処理構文。 RFCとしての考慮のためのIESGへのゲートウェイ属性分配プロトコル1月99日SubmitゲートウェイAttribute Distributionプロトコルの基礎に関する12月98日のAchieveコンセンサス、(インフォメーション、exp、stdsはTBを追跡します。
Bradner Best Current Practice [Page 25] RFC 2418 Working Group Guidelines September 1998
最も良い現在のブラドナーの練習[25ページ]RFC2418ワーキンググループガイドライン1998年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Bradner Best Current Practice [Page 26]
ブラドナーの最も良い現在の習慣[26ページ]
一覧
スポンサーリンク
