[要約] RFC 7221は、IETF Working GroupsによるInternet-Draftsの取り扱いに関するガイドラインです。このRFCの目的は、Working Groupsが効果的にInternet-Draftsを扱い、IETFプロセスに準拠するための手順を提供することです。
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7221 Juniper Networks
Category: Informational D. Crocker, Ed.
ISSN: 2070-1721 Brandenburg InternetWorking
April 2014
Handling of Internet-Drafts by IETF Working Groups
IETFワーキンググループによるインターネットドラフトの処理
Abstract
概要
The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication.
IETFワーキンググループの生産的な成果は、ワーキンググループの憲章で義務付けられているドキュメントです。ワーキンググループが特定のドキュメントを開発する準備ができている場合、最も一般的なメカニズムは、既存のドキュメントを開始点として「採用」することです。ワーキンググループが採用し、さらに開発する文書は、成熟度のさまざまなレベルでの初期入力に基づいています。最初のワーキンググループドラフトは、すでに広く使用されているドキュメントである場合もあれば、ワーキンググループによって完全に作成された空白のシートである場合もあれば、その間のあらゆるレベルの成熟度を表す場合もあります。このドキュメントでは、ワーキンググループが公開の対象となる正式なドキュメントを通常どのように処理するかについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7221.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7221で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. What Is a WG Draft? ........................................3
1.2. Working Group Authority and Consensus ......................4
1.3. Questions Considered in This Document ......................5
2. Adoption Sequence ...............................................6
2.1. Common Steps ...............................................6
2.2. Criteria for Adoption ......................................6
3. Authors/Editors .................................................8
4. Document History and Stability ..................................8
5. Some Issues for Consideration ..................................10
5.1. Individual I-Ds under WG Care .............................10
5.2. WG Drafts Can Become Individual Drafts ....................11
5.3. Competing Drafts ..........................................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. Informative References .........................................13
The productive output of an IETF working group (WG) is documents, as mandated by the working group's charter. Working groups develop these documents based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. The discussion applies only to the IETF and does not cover IRTF groups, where practices vary widely.
IETFワーキンググループ（WG）の生産的な成果は、ワーキンググループの憲章で義務付けられているドキュメントです。ワーキンググループは、さまざまな成熟度レベルでの初期入力に基づいてこれらのドキュメントを作成します。最初のワーキンググループドラフトは、すでに広く使用されているドキュメントである場合もあれば、ワーキンググループによって完全に作成された空白のシートである場合もあれば、その間のあらゆるレベルの成熟度を表す場合もあります。このドキュメントでは、ワーキンググループが公開の対象となる正式なドキュメントを通常どのように処理するかについて説明します。議論はIETFにのみ適用され、慣例が大きく異なるIRTFグループは対象外です。
Within the general constraints of formal IETF process and the specific constraints of a working group's charter, there can be considerable freedom in the adoption and development of drafts. As with most IETF activities, the ultimate arbiter of such choices is working group agreement, within the constraints of its charter. As with most working group management, this agreement might be explicit or implicit, depending upon the efficiencies that the group deems appropriate.
正式なIETFプロセスの一般的な制約とワーキンググループの憲章の特定の制約の範囲内で、ドラフトの採用と開発にはかなりの自由度があります。ほとんどのIETFアクティビティと同様に、そのような選択の最終的な裁定者は、憲章の制約の範囲内でのワーキンググループの合意です。ほとんどのワーキンググループ管理と同様に、この合意は、グループが適切であると見なした効率に応じて、明示的または暗黙的である場合があります。
NOTE: This document is intentionally non-normative. It is meant as a guide to common practice, rather than as a formal definition of what is permissible.
注：このドキュメントは、意図的に非規範的です。これは、何が許可されるかを正式に定義するものではなく、一般的な慣行のガイドとして意図されています。
Working group drafts are documents that are subject to IETF working group revision control, with advancement for publication as an RFC requiring rough consensus in the working group and then in the broader IETF. Creation or adoption of a draft by a working group -- as well as substantive changes to the document -- need to represent working group rough consensus.
ワーキンググループドラフトは、IETFワーキンググループの改訂管理の対象となるドキュメントであり、ワーキンググループとその後のより広範なIETFでの大まかなコンセンサスを必要とするRFCとしての公開の進歩を伴います。ワーキンググループによる草案の作成または採択、ならびに文書への実質的な変更は、ワーキンググループの大まかな合意を表す必要があります。
Documents under development in the IETF community are distributed as Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this mechanism for producing their official output, per Section 7.2 of [RFC2418] and Section 6.3 of [Tao]. The common convention for identifying an I-D formally under the ownership of a working group is by the inclusion of "ietf" in the second field of the I-D filename and the working group name in the third field, per Section 7 of [ID-Guidelines]. That is:
IETFコミュニティで開発中のドキュメントは、インターネットドラフト（I-D）[RFC2026] [ID-Info]として配布されます。 [RFC2418]のセクション7.2および[Tao]のセクション6.3に従い、ワーキンググループはこのメカニズムを使用して公式の出力を生成します。 [IDガイドライン]のセクション7に従い、ワーキンググループの所有権の下でIDを正式に識別するための一般的な規則は、IDファイル名の2番目のフィールドに「ietf」を、3番目のフィールドにワーキンググループ名を含めることです。 。あれは：
draft-ietf-<wgname>-...
draft-ietf- <wgname> -...
In contrast, individual submissions are drafts being created and pursued outside of a working group, although a working group might choose to adopt the draft later, as discussed below. Anyone is free to create an individual submission at any time. Such documents are typically distinguished through the use of the author/editor's last name, in the style of:
対照的に、個々の提出は、ワーキンググループが後でドラフトを採用することを選択する場合がありますが、ワーキンググループの外で作成および追求されるドラフトです。誰でもいつでも個人の提出物を自由に作成できます。このようなドキュメントは、通常、作成者/編集者の姓を次の形式で使用して区別されます。
draft-<lastname>-...
下書き-<姓> -...
(Also see Section 5.1 for an elaboration on this naming.)
（このネーミングの詳細については、セクション5.1も参照してください。）
Responsibility for direct revision of a working group I-D is assigned to its editors and authors. See Section 3 for discussion about their selection and role.
ワーキンググループI-Dの直接改訂の責任は、その編集者と著者に割り当てられています。それらの選択と役割については、セクション3を参照してください。
A premise of the IETF is that, within a working group, it is the working group itself that has final authority over the content of its documents, within the constraints of the working group's charter. No individual has special authority for the content. The Chairs assign document authors/editors and can formulate design teams, but the content of working group documents is always, ultimately, subject to working group approval. Approval is described in terms of the IETF's "rough consensus" construct, which is the prime example of the IETF's preference for pragmatics over niceties. Unanimous agreement is always desirable, but more approximate (rough) agreement will suffice, as long as it is clear and strong.
IETFの前提は、ワーキンググループ内では、ワーキンググループの憲章の制約の範囲内で、ドキュメントの内容に対する最終的な権限を持っているのがワーキンググループ自体であるということです。コンテンツに対して特別な権限を持つ個人はいない。議長はドキュメントの作成者/編集者を割り当て、設計チームを編成することができますが、ワーキンググループドキュメントの内容は常に、最終的にはワーキンググループの承認の対象となります。承認は、IETFの「大まかなコンセンサス」構成要素の観点から説明されています。これは、細かさよりも実用主義に対するIETFの選好の主な例です。満場一致の合意は常に望ましいですが、それが明確で強力である限り、より大まかな（大まかな）合意で十分です。
Other than for selection of document authors/editors, as discussed in Section 3, working group decision-making about document management is subject to normal IETF rough consensus rules. Useful descriptions of this process for a working group are in Section 3.3 of [RFC2418] and Section 4.2 of [Tao]. Discussion of the nature of rough consensus can be found in [Consensus].
セクション3で説明したように、ドキュメントの作成者/編集者を選択する場合を除き、ドキュメント管理に関するワーキンググループの意思決定は、通常のIETFの大まかなコンセンサスルールに従います。ワーキンググループに対するこのプロセスの有用な説明は、[RFC2418]のセクション3.3および[Tao]のセクション4.2にあります。大まかなコンセンサスの性質についての議論は、[コンセンサス]にあります。
In terms of the IETF's formal rough consensus processes, the working group explicitly develops, modifies, reviews, and approves document content, according to overt rough consensus. For difficult topics and/or difficult working group dynamics, this laborious process really is essential. Its diligence validates progress at each step along the way. However, working groups often handle simpler matters more simply, such as allowing a Chair to assert the likely agreement and then merely call for objections. Ultimately, the mode of working group decision-making is determined by the comfort and engagement of the working group with the way the decisions are being made.
IETFの正式な大まかなコンセンサスプロセスに関して、明白な大まかなコンセンサスに従って、ワーキンググループはドキュメントコンテンツを明示的に開発、変更、レビュー、および承認します。難しいトピックや難しいワーキンググループダイナミクスの場合、この面倒なプロセスは本当に不可欠です。その勤勉さは、道に沿った各ステップでの進捗を検証します。しかし、ワーキンググループは、議長が可能性のある合意を主張し、単に異議を唱えることを許可するなど、より単純な問題をより簡単に処理することがよくあります。最終的に、ワーキンググループの意思決定のモードは、意思決定の方法に対するワーキンググループの快適さと関与によって決まります。
At times, a document author/editor can appear to have considerable authority over content, but this is (merely) for efficiency. That is, the Chairs can permit authors and editors to proceed with an implied (default) working group agreement, as long as the working group is comfortable with that mode. Of course, the benefit in the mode is efficiency, but its risk is failure to retain or verify actual consensus among the working group participants. When a working group is operating in the mode of active, direct author/ editor content development, an easy validation method is simply to have Chairs query the working group when a new document version appears, asking for comments and concerns.
ドキュメントの作成者/編集者がコンテンツに対してかなりの権限を持っているように見えることがありますが、これは（単に）効率を上げるためです。つまり、ワーキンググループがそのモードに慣れている限り、議長は、作成者と編集者が暗黙の（デフォルト）ワーキンググループ合意に進むことを許可できます。もちろん、このモードの利点は効率ですが、そのリスクは、ワーキンググループの参加者間の実際のコンセンサスを維持または検証できないことです。ワーキンググループがアクティブな直接的な作成者/編集者コンテンツ開発モードで動作している場合、簡単な検証方法は、新しいドキュメントバージョンが表示されたときに議長にワーキンググループを照会させ、コメントや懸念事項を尋ねることです。
In general, when it is not completely obvious what the opinion of the working group is, Working Group Chairs can poll the working group to find out. As with any other consensus question, the form in which it is asked can make a difference. In particular, a general 'yes/no' question often is not as helpful as asking supporters and detractors of a draft -- or of the decision under consideration -- to provide their reasons, not merely their preferences. In effect, this treats the matter of consensus as an ongoing discussion. Ideally, the discussion can produce changes in the document or in participant views, or both.
一般に、ワーキンググループの意見が完全に明らかでない場合、ワーキンググループの議長はワーキンググループを調査して調査することができます。他のコンセンサス質問と同様に、質問の形式によって違いが生まれます。特に、一般的な「はい/いいえ」の質問は、支持者や批判者に草案（または検討中の決定）に、単に好みではなく理由を提供するよう依頼するほど役立つことはありません。実際には、これはコンセンサスの問題を進行中の議論として扱います。理想的には、ディスカッションにより、ドキュメントまたは参加者のビュー、あるいはその両方に変更を加えることができます。
The purpose of this document is to discuss the criteria and sequence typically followed when adopting and developing a formal IETF working group document. Therefore, this document considers the following questions that are particularly relevant to Working Group Chairs who are charged with running the process:
このドキュメントの目的は、正式なIETFワーキンググループドキュメントを採用および開発するときに通常従う基準と手順について説明することです。したがって、このドキュメントでは、プロセスの実行を担当するワーキンググループの議長に特に関連する次の質問について検討します。
* How do Working Group Chairs decide which drafts to adopt and when?
* ワーキンググループの議長は、どの草案をいつ採用するかをどのように決定しますか？
* Is it necessary to poll the working group explicitly, and what does a working group poll look like?
* ワーキンググループを明示的にポーリングする必要はありますか？ワーキンググループのポーリングはどのように見えますか？
* How do Working Group Chairs make the decision?
* ワーキンググループの議長はどのように決定するのですか？
* What are the process steps the working group will choose to use, for an I-D to become a WG I-D?
* I-DがWG I-Dになるために、ワーキンググループが使用することを選択するプロセスステップは何ですか？
* Are there any special cases?
* 特別な場合はありますか？
* Can a document be created as a WG I-D from scratch?
* ドキュメントを最初からWG I-Dとして作成できますか？
* How can competing drafts be handled?
* 競合するドラフトはどのように処理できますか？
* Can an individual I-D be under the care of a WG?
* 個々のI-DをWGの管理下に置くことはできますか？
* Can a WG I-D become an individual I-D?
* WG I-Dを個別のI-Dにすることはできますか？
When there is interest in adopting a document as a new working group document, the Chairs often:
文書を新しいワーキンググループ文書として採用することに関心がある場合、議長はしばしば次のことを行います。
1. Remind current draft owners that they are transferring change control for the document to the IETF. (This is a particularly significant point for a document covered by proprietary interests, because it typically entails a negotiation between the current owners and the IETF, including a formal agreement.)
1. 現在のドラフト所有者に、ドキュメントの変更管理をIETFに移していることを知らせます。 （これは通常、正式な合意を含め、現在の所有者とIETFとの間の交渉を伴うため、所有権によりカバーされるドキュメントにとって特に重要なポイントです。）
2. Check for known IPR that needs to be disclosed, using some technique like those described in [RFC6702].
2. [RFC6702]で説明されているような技術を使用して、開示する必要がある既知のIPRを確認します。
3. Obtain working group rough consensus.
3. ワーキンググループの大まかなコンセンサスを得ます。
4. Choose document editors.
4. ドキュメントエディタを選択します。
5. Instruct authors to post the WG I-D.
5. WG I-Dを投稿するように作成者に指示します。
6. Approve posting [Approval].
6. 投稿を承認します[承認]。
7. Ensure that the non-working group version of the draft is marked as being replaced by this working group version.
7. 下書きの非ワーキンググループバージョンが、このワーキンググループバージョンに置き換えられるようにマークされていることを確認します。
8. Encourage everyone to enjoy the ensuing working group discussion...
8. 次のワーキンググループディスカッションを楽しむように皆を励ましてください...
No formal specification for working group 'adoption' of a draft exists; the current document is meant to provide a description of common activities for this, but again note that it is not normative.
草案のワーキンググループの「採用」に関する正式な仕様は存在しません。現在のドキュメントは、このための一般的なアクティビティの説明を提供することを目的としていますが、これも規範的ではないことに注意してください。
There are some basic considerations when deciding to adopt a draft:
ドラフトの採用を決定する際には、いくつかの基本的な考慮事項があります。
* Is there a charter milestone that explicitly calls for such a document?
* そのような文書を明示的に要求するチャーターマイルストーンはありますか？
* Is the topic of the I-D within scope for the working group?
* I-Dのトピックはワーキンググループの範囲内ですか？
* Is the purpose of the draft sufficiently clear?
* ドラフトの目的は十分明確ですか？
* Does the document provide an acceptable platform for continued effort by the working group?
* ドキュメントは、ワーキンググループによる継続的な取り組みのための許容可能なプラットフォームを提供していますか？
* What are the process or technical objections to adoption of the draft?
* ドラフトの採用に対するプロセスまたは技術的な異議はありますか？
* Is the draft likely to be completed in a timely manner?
* ドラフトはタイムリーに完了する可能性がありますか？
* Does the intended status of the document seem reasonable to the working group?
* 文書の意図されたステータスは、ワーキンググループに合理的に見えますか？
* If not already in scope, is a simple modification to the charter feasible and warranted?
* まだ範囲内にない場合、憲章への簡単な変更は実現可能であり、保証されますか？
* Does the draft carry known intellectual property rights issues?
* 草案には既知の知的財産権問題が記載されていますか？
* Is there strong working group support for working on the draft?
* ドラフトでの作業に対する強力なワーキンググループのサポートはありますか？
Adoption has some basic pragmatics:
採用にはいくつかの基本的な実用主義があります：
Rough consensus: Working group agreement to adopt is not required to be unanimous [RFC2418].
大まかなコンセンサス：採用するワーキンググループの合意は、全会一致である必要はありません[RFC2418]。
Initial, not final: The writing quality is not required to be "ready for publication", although writing quality can be a problem and does need explicit attention; although not mandatory, it is good practice to check whether a new working group draft passes [IDNITS].
初期ではなく最終：執筆品質は「公開可能」である必要はありませんが、執筆品質は問題になる可能性があり、明示的な注意が必要です。必須ではありませんが、新しいワーキンググループドラフトが合格するかどうかを確認することをお勧めします[IDNITS]。
Adoption, not approval: The document is not required to already contain a complete and/or sufficient solution, although of course this can be helpful. Equally, adoption by a working group does not guarantee publication of the document as an RFC.
採用ではなく承認：文書は、完全かつ/または十分なソリューションをすでに含んでいる必要はありませんが、もちろんこれは役立ちます。同様に、ワーキンググループによる採用は、ドキュメントがRFCとして公開されることを保証するものではありません。
Group, not Chairs: Concerning the draft, the position of the Working Group Chairs has no special authority, except to assess working group consensus.
議長ではなくグループ：草案に関して、ワーキンググループのコンセンサスを評価することを除いて、ワーキンググループチェアのポジションには特別な権限はありません。
REMINDER: Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter. Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content. So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly.
注意：ワーキンググループがドラフトを採用すると、ドキュメントはワーキンググループによって所有され、ワーキンググループがIETFプロセスとワーキンググループチャーターの範囲内で決定した場合でも変更できます。明確な合意がない場合、ドキュメントの採用は、ワーキンググループがその内容のすべてに同意したことを自動的に意味するわけではありません。したがって、ワーキンググループ（またはその憲章）は、ドラフトのコンテンツ、技術的な詳細などの一部またはすべてを保持、削除、または変更するための基礎を明示的に指示する場合があります。ただし、そのような制約がない場合は、採用プロセスに、既存のドラフトに関するワーキンググループの懸念を収集し、それらに明示的にフラグを立てるサブプロセスを含める価値があります。
Document authors/editors are chosen by the Working Group Chairs. Document editors are described in Section 6.3 of [RFC2418]. Authors and editors are described in [RFC-Auth-Ed].
ドキュメントの作成者/編集者は、ワーキンググループの議長によって選ばれます。ドキュメントエディタについては、[RFC2418]のセクション6.3で説明されています。著者と編集者は、[RFC-Auth-Ed]で説明されています。
NOTE: In this document, the terms 'author' and 'editor' are meant interchangeably. Within the IETF, the distinction between an 'author' and an 'editor' is, at best, subjective. A simplistic rule of thumb is that editors tend to do the mechanics of incorporating working group detail, whereas authors tend to create the detail, subject to working group approval. That is, one role is more active with the content, and the other is more passive. It is a responsibility of the Working Group Chairs to ensure that document authors make modifications in accord with working group rough consensus. Authors/editors are solely chosen by the Chairs -- although the views of the working group should be considered -- and are subject to replacement for a variety of reasons, as the Chairs see fit.
注：このドキュメントでは、「作成者」と「編集者」という用語は同じ意味で使用されています。 IETF内では、「作成者」と「編集者」の区別は、せいぜい主観的なものです。単純な経験則では、編集者はワーキンググループの詳細を組み込むメカニズムを行う傾向がありますが、作成者はワーキンググループの承認に従って詳細を作成する傾向があります。つまり、1つの役割はコンテンツに対してよりアクティブであり、もう1つの役割はよりパッシブです。文書作成者がワーキンググループの大まかな合意に従って変更を加えるようにすることは、ワーキンググループチェアの責任です。著者/編集者は、ワーキンググループの見解を考慮に入れるべきですが、専ら議長によって選ばれ、議長が適切と考えるさまざまな理由で置き換えられます。
For existing documents that are being adopted by a working group, there is a special challenge in the selection of document editors. Because the document has already had editors, the question "Are the same people appropriate for continuing the task?" is asked. Sometimes the answer is yes, but this is not automatic. The process within an IETF working group can be quite different from the process that created previous versions. This well might make it appropriate to select one or more new editors, either as additions to the editor team or as primary pen-holders (effectively reclassifying the previous team as coauthors).
ワーキンググループで採用されている既存のドキュメントの場合、ドキュメントエディターの選択には特別な課題があります。ドキュメントにはすでに編集者がいるため、「同じ人が作業を続けるのに適切ですか？」という質問尋ねられます。時々答えはイエスですが、これは自動的ではありません。 IETFワーキンググループ内のプロセスは、以前のバージョンを作成したプロセスとはかなり異なる場合があります。このため、1人以上の新しい編集者を、編集チームへの追加として、または主要なペンホルダーとして選択することが適切な場合があります（前のチームを共著者として効果的に再分類します）。
If the original editors are to continue in their role, the Chairs might want to ensure that the editors understand IETF working group process; it is likely to be quite different from the process that developed earlier versions of the document. If additional or new editors are assigned, the transition can be discussed, including its reasons; this is best done as soon as possible.
元の編集者がその役割を継続する場合、議長は、編集者がIETFワーキンググループのプロセスを確実に理解できるようにしたい場合があります。以前のバージョンのドキュメントを開発したプロセスとはかなり異なる可能性があります。追加または新しいエディターが割り当てられた場合、その理由を含めて、移行について話し合うことができます。これはできるだけ早く行うのが最善です。
Working group charters sometimes specify an initial set of existing documents to use as a basis of the working group's activities. That 'basis' can vary considerably, from simple input to working group discussion, all the way to an advanced draft adopted by the working group and subject only to minimal changes. The role of a document should be explicitly stated in the charter.
ワーキンググループチャーターは、ワーキンググループの活動の基礎として使用する既存のドキュメントの初期セットを指定することがあります。その「基礎」は、単純な入力からワーキンググループディスカッションまで、ワーキンググループによって採用された高度なドラフトまで、かなり変化する可能性があり、最小限の変更のみが適用されます。文書の役割は憲章に明確に述べられるべきです。
Within the scope of its charter, a working group is free to create new documents. It is not required that all drafts start as the effort of an individual. Of course, the criteria for brand new documents are likely to be the same as for those imported into the working group, with the additional and obvious requirement that the Working Group Chairs will need to appoint authors/editors before any work can progress. Note that, from time to time, a working group will form a design team to produce the first version of a working group draft. Design teams are discussed in Section 6.5 of [RFC2418].
憲章の範囲内で、ワーキンググループは新しいドキュメントを自由に作成できます。すべてのドラフトが個人の努力として始まる必要はありません。もちろん、新しいドキュメントの基準はワーキンググループにインポートされたものと同じである可能性が高く、作業を進める前にワーキンググループの議長が作成者/編集者を指名する必要があるという追加の明白な要件があります。時々、ワーキンググループがワーキンググループドラフトの最初のバージョンを作成する設計チームを編成することに注意してください。設計チームについては、[RFC2418]のセクション6.5で説明されています。
Work that is brought to the IETF has different levels of completeness and maturity, and different timings for having achieved those levels. When the IETF charters a group and includes existing material, the charter can cast the role of that material in very different ways. It can treat it as:
IETFにもたらされる作業は、完全性と成熟度のレベルが異なり、それらのレベルを達成するためのタイミングも異なります。 IETFがグループをチャーターし、既存の資料を含める場合、チャーターはその資料の役割を非常に異なる方法でキャストできます。それは次のように扱うことができます：
* no more than a set of ideas, to be used or ignored;
* 使用または無視されるアイデアのセットにすぎません。
* a basic design, with all of the actual details still fluid;
* 基本的なデザインで、実際の詳細はすべて流動的です。
* a rough draft, subject to extensive revision;
* 大まかな草案であり、大幅な改訂が必要です。
* a solid specification that merely needs review, refinement, and maybe enhancement;
* レビュー、改良、そしておそらく拡張が必要なだけの堅固な仕様。
* a deployed technology that is best served by trying to protect its installed base, but with some tolerance for changes that affect interoperability;
* インストールされたベースを保護しようとすることによって最も効果的に機能するが、相互運用性に影響を与える変更にはある程度の許容度があるデプロイされたテクノロジー。
* a deployed technology for which protecting the installed base is essential, including retention of core interoperability.
* コア相互運用性の保持を含む、インストール済みベースの保護が不可欠である展開されたテクノロジー。
These suggest a wide range of possible constraints on working group effort. Technology is brought to the IETF at different points of maturity along its life cycle, and the nature of the technology can have widely varying utility in developing an Internet standard.
これらは、ワーキンググループの取り組みに対する幅広い可能な制約を示唆しています。テクノロジーは、そのライフサイクルに沿ったさまざまな成熟点でIETFにもたらされます。また、テクノロジーの性質により、インターネット標準を開発する上でさまざまなユーティリティを使用できます。
When technology is brand new, with at most some prototypes done as proofs of concept, then significant changes to the specification will not necessarily add much to the development and deployment costs. However, when the technology is already part of a mature and extensive operational deployment, any changes that are incompatible are likely to be problematic for that market and can hinder adoption of the changes overall. For example, immediately after the development investment is made -- and especially when there has been considerable initial deployment but there is still room for quite a bit more -- the installed and potential base might not take kindly to disruptive standards work that undermines their recent investment.
テクノロジーがまったく新しいものであり、多くのプロトタイプが概念実証として行われている場合、仕様への大幅な変更によって、必ずしも開発および導入コストが増えるわけではありません。ただし、テクノロジーがすでに成熟した大規模な運用展開の一部である場合、互換性のない変更はその市場にとって問題となる可能性が高く、変更全体の採用を妨げる可能性があります。たとえば、開発投資が行われた直後-特に初期の展開がかなり進んでいるが、まだかなりの余地がある場合-インストールされている可能性のあるベースは、最近の開発を損なう破壊的な標準作業に親切にならない可能性があります投資。
Conversely, even a deployed technology with a solid base might be inappropriate to deploy at Internet scale, and while a document specifying such a technology might serve as a good starting point on which to base a new specification, undermining of the deployed base might be completely appropriate.
逆に、強固な基盤を持つ展開されたテクノロジーでさえ、インターネット規模での展開には不適切である可能性があり、そのようなテクノロジーを指定するドキュメントは、新しい仕様のベースとなる良い出発点として役立つかもしれませんが、展開されたベースの弱体化は完全になる可能性があります適切な。
In reflecting upon the basis for adopting an existing draft and the way it will be used by the working group, it is important to consider the document's place in its life cycle, the needs of any installed base, and the applicability of the draft's technology, when deciding on the constraints to impose on document development. It will all depend on the constraints of the charter and the analysis of the working group.
既存のドラフトを採用するための根拠とワーキンググループによる使用方法を反映する上で、そのライフサイクルにおけるドキュメントの場所、インストールベースのニーズ、およびドラフトのテクノロジーの適用性を考慮することが重要です。ドキュメント開発に課す制約を決定するとき。それはすべて憲章の制約とワーキンググループの分析に依存します。
Sometimes, a working group facilitates a draft but does not own it or formally adopt it. These are "individual" drafts [Individual].
時々、ワーキンググループはドラフトを促進しますが、それを所有したり正式に採用したりしません。これらは「個人」の下書きです[個人]。
As noted in Section 1.1 and reinforced in [ID-Guidelines], the convention for identifying an I-D formally under the ownership of a working group is by following the naming convention:
セクション1.1で述べられ、[IDガイドライン]で強化されたように、ワーキンググループの所有権の下でI-Dを正式に識別するための規則は、命名規則に従うことです。
draft-ietf-<wgname>-...
draft-ietf- <wgname> -...
By contrast, documents that are still under the control of their authors are known as "individual" I-Ds. When these documents are intended for consideration by a specific working group, the convention is that the document uses the naming convention as follows, where the second element is the last name of one of the principal authors.
対照的に、まだ作成者の管理下にあるドキュメントは、「個別の」I-Dとして知られています。これらのドキュメントが特定のワーキンググループによる検討を目的としている場合、規則では、ドキュメントは次のような命名規則を使用します。2番目の要素は、主要な作成者の1人の姓です。
draft-<lastname>-<wgname>...
ドラフト-<姓>-<wgname> ...
Having the working group name following the personal name allows tools to associate these drafts with the working group, even though the filename identifies them as the work of individuals.
個人名の後にワーキンググループ名を付けると、ファイル名で個人の作品として識別されていても、ツールでこれらの下書きをワーキンググループに関連付けることができます。
The working group can choose to apply any of its normal, internal working group process management mechanisms to an individual I-D. However, matters of ownership, working group final approval, and the like are all subject to negotiation amongst the document authors, working group, and Area Directors.
ワーキンググループは、通常の内部ワーキンググループプロセス管理メカニズムを個々のI-Dに適用することを選択できます。ただし、所有権、ワーキンググループの最終承認などの問題はすべて、ドキュメントの作成者、ワーキンググループ、およびエリアディレクターの間で交渉の対象となります。
This is a rare situation, and Working Group Chairs can be assured that the Area Directors will want to understand why the document could not be adopted and owned by the working group.
これはまれな状況であり、ワーキンググループの議長は、エリアディレクターがこの文書をワーキンググループが採用および所有できない理由を理解することを望んでいることを確信できます。
A working group is not obligated to retain documents it has adopted. Sometimes working group efforts conclude that a draft is no longer appropriate for working group effort. If a working group drops a draft, then anyone is permitted to pursue it as an Individual or Independent Submission, subject to the document's existing copyright constraints.
ワーキンググループは、採用したドキュメントを保持する義務はありません。ワーキンググループの取り組みにより、ドラフトはワーキンググループの取り組みにもはや適切ではないと結論付けられる場合があります。ワーキンググループがドラフトを削除した場合、ドキュメントの既存の著作権の制限に従い、誰でもそれを個人または独立した提出物として追跡することが許可されます。
Engineering for interesting topics often produces competing, interesting proposals. The reasons can be technical aesthetics, engineering trade-offs, architectural differences, company economics, and the like. Although it is far more comfortable to entertain only one proposal, a working group is free to pursue more than one. Often this is necessary until a clear preference develops. Sometimes, multiple versions are formally published, absent consensus among the alternatives.
興味深いトピックのエンジニアリングは、しばしば競合する興味深い提案を生み出します。その理由は、技術的な美学、エンジニアリングのトレードオフ、アーキテクチャの違い、企業の経済性などです。 1つの提案だけを受け入れる方がはるかに快適ですが、作業グループは複数を自由に追求できます。多くの場合、これは明確な好みが生じるまで必要です。時々、複数のバージョンが正式に公開され、代替案間の合意がない場合があります。
It is appealing to ask authors of competing proposals to find a way to merge their work. Where it makes sense to do this, it can produce a single, strong specification. The detailed discussions to merge are often better held in a design team than amidst the dynamics of an open working group mailing list. The working group has ultimate authority over any decisions, but it is not required that it be involved in all the discussions.
競合する提案の作者に彼らの仕事をマージする方法を見つけるように頼むことは魅力的です。これを行うのが理にかなっている場合は、単一の強力な仕様を作成できます。多くの場合、統合する詳細な議論は、オープンワーキンググループのメーリングリストのダイナミクスの中で行われるよりも、設計チームで行う方が適切です。ワーキンググループはあらゆる決定に対して最終的な権限を持っていますが、すべての議論に関与する必要はありません。
On the other hand, some differences cannot be resolved, and attempting a merge can produce a weaker result. An example of this problem of conflicting design goals is discussed in [Heli-Sub], noting:
一方、いくつかの違いは解決できず、マージを試みるとより弱い結果が生成される可能性があります。競合する設計目標のこの問題の例は、[Heli-Sub]で説明されています。
"Helicopters are great, and so are submarines. The problem is that if you try to build one vehicle to perform two fundamentally different jobs, you're going to get a vehicle that does neither job well."
「ヘリコプターは素晴らしく、潜水艦も同様です。問題は、1つの車両を構築して2つの根本的に異なる仕事を実行しようとすると、どちらもうまく機能しない車両を手に入れることになるということです。」
Various management efforts can facilitate the handling of competing proposals. Some examples include:
さまざまな管理努力により、競合する提案の処理が容易になります。いくつかの例は次のとおりです。
* Developing a requirements document that is independent of specific proposals; this can highlight features that are deemed essential and distinguish them from features that are of secondary importance, and can facilitate a discussion about features without reference to specific proposals.
* 特定の提案に依存しない要件文書を作成する。これにより、必須と見なされる機能を強調表示し、それらを2番目に重要な機能と区別し、特定の提案を参照せずに機能についての議論を促進できます。
* Developing a comparison table of the proposals; this can aid understanding of their differences.
* 提案の比較表を作成する。これは、それらの違いを理解するのに役立ちます。
* Discussing the relative importance and effects of having one proposal, versus multiple; this can focus people's efforts at compromise and encourage a willingness to choose a single proposal.
* 複数の提案に対する1つの提案の相対的な重要性と影響について話し合う。これにより、人々の妥協への取り組みを集中させ、単一の提案を選択する意欲を促すことができます。
The problem of competing drafts can be particularly painful when it arises in either of two circumstances:
ドラフトの競合の問題は、次の2つの状況のいずれかで発生した場合に特に痛みを伴います。
* If a second proposal appears as a new draft, just as the Chairs were ready to poll the working group on adoption of the draft containing the first proposal, then the authors of the first proposal could feel affronted. It does not follow that the second draft was written to be difficult or derail the first: it might even include better ideas. So it is best not to disregard it. However, automatically asking the authors to merge their work will not necessarily produce a more solid solution and will not guarantee faster progress. This situation will be a judgement call in each case, and it might help to ask the working group for their opinion: shall the working group adopt one document as a starting point and fold in the ideas from the second under the control of consensus, or shall the working group wait until the authors of both documents have reached agreement?
* 議長が最初の提案を含む草案の採択についてワーキンググループに投票する準備ができているのと同じように、2番目の提案が新しい草案として表示される場合、最初の提案の執筆者は失望するかもしれません。 2番目のドラフトが難解であるか最初のドラフトを狂わせるように書かれているとは限りません。より良いアイデアが含まれている可能性さえあります。したがって、それを無視しないことをお勧めします。ただし、作成者に自分の作業をマージするように自動的に要求することは、必ずしもより確実な解決策を生み出すわけではなく、より速い進歩を保証するものではありません。この状況は、いずれの場合も判断の呼びかけとなり、ワーキンググループに意見を求めるのに役立つ可能性があります。ワーキンググループは、1つのドキュメントを出発点として採用し、コンセンサスの制御下で2番目のドキュメントからアイデアを折りたたむか、ワーキンググループは、両方のドキュメントの作成者が合意に達するまで待機する必要がありますか？
* If the working group has already adopted an I-D on a specific topic, the posting of a new individual I-D on the same topic could be seen as an attack on the working group processes or decisions. However, posting an I-D is often a good way to put new ideas into concrete form, for public consideration and discussion. The Working Group Chairs will want to encourage the working group to consider the new proposal. Shall it be adopted and entirely replace the current working group draft? Shall the new ideas be incorporated into the work of the working group through the normal editorial process? Shall the working group adopt a second competing solution? Or shall the new draft be rejected and not adopted by the working group?
* ワーキンググループが特定のトピックに既にI-Dを採用している場合、同じトピックに新しい個別のI-Dを投稿することは、ワーキンググループのプロセスまたは決定に対する攻撃と見なされる可能性があります。ただし、I-Dを投稿することは、新しいアイデアを具体的な形にして、一般の検討や議論に役立てるための良い方法です。ワーキンググループの議長は、ワーキンググループが新しい提案を検討するよう奨励したいと思うでしょう。それを採用して、現在のワーキンググループドラフトを完全に置き換えますか？新しいアイデアは、通常の編集プロセスを通じてワーキンググループの作業に組み込まれますか？ワーキンググループは2番目の競合ソリューションを採用する必要がありますか？あるいは、新しい草案は拒否され、ワーキンググループによって採択されないのでしょうか？
Beyond the credibility of the IETF, this document raises no security concerns.
IETFの信頼性を超えて、このドキュメントはセキュリティ上の問題を提起しません。
This document was developed from an IETF tutorial given by A. Farrel at an IETF Working Group Chairs lunch [Farrel-Chairs]. L. Anderson contributed useful comments.
このドキュメントは、A。FarrelがIETFワーキンググループの議長のランチ[Farrel-Chairs]で提供したIETFチュートリアルから作成されました。 L.アンダーソンは有益なコメントを投稿しました。
[Approval] IETF, "IETF Internet-Draft Initial Version Approval Tracker", (IETF Datatracker), <https://datatracker.ietf.org/ cgi-bin/wg/wg_init_rev_approval.cgi>.
[承認] IETF、「IETF Internet-Draft Initial Version Approval Tracker」、（IETF Datatracker）、<https://datatracker.ietf.org/ cgi-bin / wg / wg_init_rev_approval.cgi>。
[Consensus] Resnick, P., "On Consensus and Humming in the IETF", Work in Progress, April 2014.
[コンセンサス] Resnick、P。、「IETFにおけるコンセンサスとハミングについて」、進行中の作業、2014年4月。
[Farrel-Chairs] Farrel, A., "What is a Working Group ID (and when to adopt one)", (IETF 78 WG chairs lunch Material), July 2010, <http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>.
[Farrel-Chairs] Farrel、A.、「ワーキンググループIDとは（およびいつ採用するか）」、（IETF 78 WG議長の昼食資料）、2010年7月、<http://wiki.tools.ietf.org / group / edu / wiki / IETF78＃>。
[Heli-Sub] Rose, M., "On Helicopters and Submarines", ACM Queue - Instant Messaging, Vol. 1, Issue 8, Page 10, <http://dl.acm.org/ft_gateway.cfm?id=966726>.
[Heli-Sub] Rose、M。、「On Helicopters and Submarines」、ACM Queue-Instant Messaging、Vol。 1、問題8、ページ10、<http://dl.acm.org/ft_gateway.cfm?id=966726>。
[ID-Guidelines] Housley, R., Ed., "Guidelines to Authors of Internet-Drafts", December 2010, <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[IDガイドライン] Housley、R。、編、「インターネットドラフト作成者向けガイドライン」、2010年12月、<http://www.ietf.org/ietf-ftp/1id-guidelines.txt>。
[ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) submitted for RFC publication", May 2009, <https://www.ietf.org/id-info/checklist.html>.
[ID情報] Wijnen、B。、編、「RFC公開用に提出されたインターネットドラフト（ID）のチェックリスト」、2009年5月、<https://www.ietf.org/id-info/checklist.html> 。
[IDNITS] IETF, "IDNITS Tool", 2013, <https://tools.ietf.org/tools/idnits/>.
[IDNITS] IETF、「IDNITSツール」、2013、<https://tools.ietf.org/tools/idnits/>。
[Individual] IESG, "Guidance on Area Director Sponsoring of Documents", March 2007, <http://www.ietf.org/iesg/statement/ ad-sponsoring-docs.html>.
[個人] IESG、「ドキュメントのエリアディレクタースポンサーシップに関するガイダンス」、2007年3月、<http://www.ietf.org/iesg/statement/ ad-sponsoring-docs.html>。
[RFC-Auth-Ed] RFC Editor, "RFC Editorial Guidelines and Procedures -- Author Overload", 2014, <http://www.rfc-editor.org/policy.html#policy.authlist>.
[RFC-Auth-Ed] RFC Editor、「RFC Editorial Guidelines and Procedures-Author Overload」、2014、<http://www.rfc-editor.org/policy.html#policy.authlist>。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
[RFC2418] Bradner、S。、「IETF Working Group Guidelines and Procedures」、BCP 25、RFC 2418、1998年9月。
[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", RFC 6702, August 2012.
[RFC6702] Polk、T。およびP. Saint-Andre、「知的財産権（IPR）開示規則の遵守の促進」、RFC 6702、2012年8月。
[Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", 2012, <http://www.ietf.org/tao.html>.
[タオ]ホフマン、P。、編、「IETFのタオ-インターネットエンジニアリングタスクフォースの初心者向けガイド」、2012年、<http://www.ietf.org/tao.html>。
Authors' Addresses
著者のアドレス
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
EMail: adrian@olddog.co.uk
Dave Crocker (editor) Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
Dave Crocker（編集者）Brandenburg InternetWorking 675 Spruce Drive Sunnyvale、CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net