RFC 3933 - A Model for IETF Process Experiments 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3933
タイトル : RFC 3933 - IETFプロセス実験のモデル
翻訳編集 : 自動生成

[要約] RFC 3933は、IETFプロセスの実験に関するモデルであり、IETFコミュニティによる新しいアイデアや手法の評価と導入を支援することを目的としています。

Network Working Group                                         J. Klensin
Request for Comments: 3933                                    S. Dawkins
BCP: 93                                                    November 2004
Category: Best Current Practice

A Model for IETF Process Experiments

IETFプロセス実験のモデル

Status of this Memo

本文書の位置付け

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

著作権表示

著作権（c）The Internet Society（2004）。

Abstract

概要

The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight.

IETFは、過去10年間にわたって、IESGによる発表、時にはコミュニティの関与と意識が限られている非公式の合意に基づいて、プロトコル仕様に使用される同じメカニズムの正式な使用に基づいて、プロセスの変更を設計しました。最初のメカニズムは、しばしば軽量であることが証明されており、2番目のメカニズムはヘビー級であることが証明されています。

This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted.

このドキュメントは、IETFプロセスを変更するシステムへの中間地面のアプローチを指定します。これは、「実験を提案し、実施し、実験を評価し、運用経験に基づいて恒久的な手順を確立する」モデルではなく、恒久的な手順を確立する」ことを指定しています。以前に試みられました。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Background and Specification . . . . . . . . . . . . . . . . . 2
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 5
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
       5.1.  Normative Reference. . . . . . . . . . . . . . . . . . . 5
       5.2.  Informative References . . . . . . . . . . . . . . . . . 5
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7

1. Introduction

1. はじめに

2. Background and Specification

2. 背景と仕様

Since the 1992 changes documented in [RFC1396], the IETF has used two mechanisms for process changes.

[RFC1396]に文書化された1992年の変更以来、IETFはプロセスの変更に2つのメカニズムを使用しています。

1. IESG has adopted a number of procedural changes on its own initiative and documented them informally, utilizing the wide discretion implicitly granted to them by [RFC2026]. This provided a lightweight mechanism for change, but the lightness came with a cost: There was sometimes too little alignment with the larger IETF community.

1. IESGは、独自のイニシアチブで多くの手続き上の変更を採用し、非公式に文書化し、[RFC2026]によって暗黙的に付与された幅広い裁量を利用しています。これにより、変化の軽量メカニズムが提供されましたが、軽さにはコストがかかりました。より大きなIETFコミュニティとの整合性が少なすぎる場合がありました。

2. The IETF has also used the [RFC2026] protocol standards development process to identify a community of interest, hold one or more BoFs, charter a working group, discuss proposed changes within the community, develop IETF-wide consensus on the changes, and publish (usually) Best Current Practice specifications. This provided full community involvement but also came with a cost in flexibility. The IETF does not change its formal processes often (the IPR clarifications in [RFC3667, RFC3668] are the first documented changes to [RFC2026] since 1996), and the community is understandably reluctant to permanently alter or extend formally adopted processes with untried new procedures.

2. IETFは、[RFC2026]プロトコル標準開発プロセスを使用して、関心のあるコミュニティを特定し、1つ以上のBOFSを保持し、ワーキンググループをチャーターし、コミュニティ内で提案された変更について議論し、変更に関するIETF全体のコンセンサスを開発し、公開しています（通常）最良の現在の練習仕様。これにより、コミュニティの完全な関与が提供されましたが、柔軟性のコストも伴いました。IETFは、正式なプロセスを頻繁に変更しません（[RFC3667、RFC3668]のIPR明確化は、1996年以来[RFC2026]の最初の文書化された変更です）。。

There is a middle ground between BCP process updates and informal agreements. This document specifies regularizing and formalizing the informal IESG mechanisms listed in 1 above as a means of moving forward with procedural changes that might prove valuable.

BCPプロセスの更新と非公式の契約の間には、中間点があります。このドキュメントは、価値があると証明される手続き上の変更を進める手段として、上記の1にリストされている非公式のIESGメカニズムの正規化と形式化を指定します。

The mechanisms outlined here add to the IESG's range of tools for dealing with process issues on an ongoing basis. They supplement the existing tools rather than attempting to replace them with a single "magic bullet". The choice of using the procedure outlined in this document or other mechanisms available to the IESG and the community -- present or future -- remains in the IESG's hands. If the IESG does not exercise this discretion wisely, this document provides no additional remedies.

ここで概説されているメカニズムは、継続的にプロセスの問題を扱うためのIESGのツールの範囲に追加されます。それらは、単一の「魔法の弾丸」に置き換えようとするのではなく、既存のツールを補完します。このドキュメントで概説されている手順またはIESGとコミュニティが利用できるその他のメカニズム（現在または将来）を使用するという選択は、IESGの手に残っています。IESGがこの裁量を賢明に行使しない場合、このドキュメントは追加の救済策を提供しません。

Some have interpreted the current procedures as giving the IESG all of the capabilities outlined here. If this were true, this document only encourages the IESG to use this type of mechanism more frequently in preference to less streamlined ones, and to more explicitly document its actions and decisions.

一部の人々は、現在の手順を、ここで概説したすべての機能をIESGに提供すると解釈しています。これが当てはまる場合、このドキュメントは、IESGがこのタイプのメカニズムをより頻繁に使用することをより頻繁に使用することを奨励しているだけです。

This specification permits and encourages the IESG to adopt and institute "process experiments" by using the following procedure:

この仕様は、次の手順を使用して、IESGが「プロセス実験」を採用および制定することを許可し、奨励します。

1. An I-D is written describing the proposed new or altered procedure. A statement of the problem expected to be resolved is desirable but not required (the intent is to keep the firm requirements for such an experiment as lightweight as possible). Similarly, specific experimental or evaluative criteria, although highly desirable, are not required -- for some of the process changes we anticipate, having the IESG reach a conclusion at the end of the sunset period that the community generally believes things to be better (or worse) will be both adequate and sufficient. The I-D must state an explicit "sunset" timeout typically, not to exceed one year after adoption.

1. I-Dは、提案された新しいまたは変更された手順を説明する記述されています。解決されると予想される問題の声明は望ましいが必須ではない（そのような実験の確定要件を可能な限り軽量に保つことは目的ではない）。同様に、特定の実験的または評価基準は、非常に望ましいものの、必要ではありませんが、予想されるプロセスの変更の一部には、IESGが日没期間の終わりに、コミュニティが一般的に物事がより良いと信じているという結論に達する（またはさらに悪い）は適切かつ十分です。I-Dは、通常、養子縁組後1年を超えないように、明示的な「日没」タイムアウトを記載する必要があります。

2. If the IESG believes the proposal is plausible and plausibly useful, a four-week IETF Last Call is initiated. The IESG can institute whatever procedures it wishes to make this determination and to avoid denial of service attacks from large numbers of spurious or unimportant proposals. In particular, they might institute a procedure requiring a number of endorsements, or endorsements of a particular type, before the IESG considers the proposal. The IESG is, however, expected to understand that procedures or review processes that act as a mechanism for significant delays do not fall within the intent of this specification.

2. IESGが提案がもっともらしいともっともらしいと信じている場合、4週間のIETF最後の呼び出しが開始されます。IESGは、この決定を下したいと思うあらゆる手順を制定し、多数の偽のまたは重要でない提案からのサービス攻撃の拒否を回避することができます。特に、IESGが提案を検討する前に、特定のタイプの多くの承認または承認を必要とする手順を制定するかもしれません。ただし、IESGは、大幅な遅延のメカニズムとして機能する手順またはレビュープロセスがこの仕様の意図に該当しないことを理解することが期待されています。

3. At the conclusion of the Last Call, the IESG reevaluates the plausibility and appropriateness of the proposal. If they conclude that the proposed experiment is appropriate, a second I-D is generated (either by the IESG or by the original authors with IESG advice) that cleans up any definitional issues exposed in the Last Call and that explicitly identifies and responds to issues raised during the Last Call.

3. 最後の呼び出しの終わりに、IESGは提案の妥当性と適切性を再評価します。提案された実験が適切であると結論付けた場合、最後の呼び出しで公開された定義上の問題をクリーンアップするために、2番目のI-Dが（IESGまたはIESGアドバイスを含む元の著者のいずれかによって）生成され、その際に提起された問題を明示的に識別して応答することが生成されます。最後の呼び出し。

4. The document and experiment are then announced, the experiment is begun, and the document is forwarded for publication as an Experimental RFC.

4. その後、ドキュメントと実験が発表され、実験が開始され、文書は実験RFCとして公開されるために転送されます。

The IESG is explicitly authorized to use this mechanism (based on Experimental RFCs) to gain experience with proposed changes to BCP specifications. There is no requirement to approve a BCP specification for the experiment until the experiment is found to have value.

IESGは、このメカニズム（実験RFCに基づく）を使用して、BCP仕様の変更された変更の経験を積むことを明示的に許可されています。実験が価値があることが判明するまで、実験のBCP仕様を承認する必要はありません。

The IESG could, of course, reach a "bad idea" conclusion at any stage in this process and abandon the experiment. It might recommend publication of the experimental document, with a discussion of why it was a bad idea, but is not required to do so. The list above is deliberately vague about where the I-Ds come from: a WG, design team, individual contribution, editing group, or other mechanism could be used in the first and/or third steps, but no specific mechanisms are required, and the IESG is explicitly permitted to generate such proposals internally.

もちろん、IESGは、このプロセスのあらゆる段階で「悪い考え」の結論に達し、実験を放棄することができます。実験文書の公開を推奨するかもしれません。なぜそれが悪い考えであるかについての議論を伴いますが、そうする必要はありません。上記のリストは、I-DSがどこから来たのかについて意図的に曖昧です。WG、設計チーム、個別の貢献、編集グループ、またはその他のメカニズムは、第1ステップおよび/または3番目のステップで使用できますが、特定のメカニズムは必要ありません。IESGは、そのような提案を内部的に生成することを明示的に許可されています。

In each case, the IESG's decision to go forward (or not) with a procedural experiment, or the steps leading up to one, is expected to reflect their judgment of the existence of rough consensus in the community. That judgment may be appealed using the usual procedures, but the IESG and the community are reminded that an experimental attempt to try something for a fixed period is typically a better engineering approach than extended philosophical discussion without any experience to back it up.

いずれの場合も、IESGが手続き上の実験または1つまでのステップで前進する（または進んでいない）決定は、コミュニティにおける大まかなコンセンサスの存在の判断を反映することが期待されています。その判断は通常の手順を使用して上訴されるかもしれませんが、IESGとコミュニティは、固定期間を試みようとする実験的な試みは、通常、それをバックアップする経験なしに拡張された哲学的議論よりも優れたエンジニアリングアプローチであることを思い出させます。

Nothing above is to be construed as requiring an IETF-wide attempt for any given process experiment. A proposal for such an experiment may specify selected areas, selected working groups, working groups meeting some specific criteria (e.g., those created after a particular time or of a specified age), or be specific in other ways.

上記のものは、特定のプロセス実験に対してIETF全体の試みを必要とすると解釈されるものではありません。このような実験の提案は、選択された領域、選択されたワーキンググループ、特定の基準（特定の時間または特定の年齢の後に作成されたものなど）を満たすワーキンググループ、または他の方法で特定のものを指定する場合があります。

At or before the end of the "sunset" timeout, the IESG would either revise (or cause to be revised) the document into a BCP RFC or the procedure would expire and, presumably, not be tried again unless something changed radically. A document describing why the experiment had succeeded or failed would be desirable but could not, realistically, be a requirement. If the procedure went to BCP, the BCP would reflect what we would call "operational experience" in the real world.

「日没」のタイムアウトの終わり以前に、IESGは文書をBCP RFCに修正する（または改訂する）か、手順が期限切れになり、おそらく何かが根本的に変更されない限り再試行されないでしょう。実験が成功または失敗した理由を説明する文書は、現実的には要件ではありませんでした。手順がBCPに進んだ場合、BCPは現実の世界で「運用経験」と呼ばれるものを反映します。

We note that, if the procedures the IESG has adopted (and the procedural exceptions it has made) over the last decade are legitimate, then the IESG has the authority to institute the changes specified here by bootstrapping this process.

過去10年間でIESGが採用した手順（およびそれが行った手続き上の例外）が合法である場合、IESGはこのプロセスをブートストラップすることによりここで指定された変更を制定する権限を持っていることに注意してください。

3. Security Considerations

3. セキュリティに関する考慮事項

This document specifies a mechanism for evolving IETF procedures. It does not raise or consider any protocol-specific security issues. In considering experimental changes to procedures, the IESG should, of course, exercise due caution that such changes not reduce the quality of security review and consideration for protocols or, at least, that the process experiment proposals contain early detection and correction mechanisms should quality deterioration occur.

このドキュメントは、進化するIETF手順のメカニズムを指定します。プロトコル固有のセキュリティの問題を提起したり考慮したりしません。手順の実験的な変更を検討する際に、IESGはもちろん、そのような変更がセキュリティレビューの質とプロトコルの考慮を低下させないこと、または少なくともプロセス実験の提案に早期検出と修正メカニズムが質の高い劣化を含める必要があることに注意する必要があります。起こる。

4. Acknowledgements

4. 謝辞

The first revision of this document benefited significantly from suggestions and comments from Avri Doria, Margaret Wasserman, and Harald Alvestrand, and from discussions with the General Area Directorate and at its open meeting during IETF 59. After mailing list discussion, considerable explanatory material was removed to a separate document for the current version.

この文書の最初の改訂は、Avri Doria、Margaret Wasserman、およびHarald Alvestrandからの提案とコメント、およびIETF 59の一般的なエリア局との議論から、郵送リストの議論の後、かなりの説明資料が削除されたことから、かなりの説明資料が削除されたため、一般的なエリア局との議論から恩恵を受けました。現在のバージョンの個別のドキュメントに。

The first version of this document was posted as an Internet Draft on February 7, 2004.

このドキュメントの最初のバージョンは、2004年2月7日にインターネットドラフトとして投稿されました。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[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月。

5.2. Informative References

5.2. 参考引用

[RFC1396] Crocker, S., "The Process for Organization of Internet Standards Working Group (POISED)", RFC 1396, January 1993.

[RFC1396] Crocker、S。、「インターネット標準組織ワーキンググループの組織プロセス（Poided）」、RFC 1396、1993年1月。

[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004.

[RFC3667] Bradner、S。、「貢献におけるIETFの権利」、BCP 78、RFC 3667、2004年2月。

[RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004.

[RFC3668] Bradner、S。、「IETFテクノロジーの知的財産権」、BCP 79、RFC 3668、2004年2月。

6. Authors' Addresses

6. 著者のアドレス

John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA

ジョンCクレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140 USA

   Phone: +1 617 491 5735
   EMail: john-ietf@jck.com

Spencer Dawkins 1547 Rivercrest Blvd. Allen, TX 75002 USA

スペンサー・ドーキンス1547 Rivercrest Blvd.アレン、テキサス75002 USA

   Phone: +1 469 330 3616
   EMail: spencer@mcsr-labs.org

Full Copyright Statement

完全な著作権声明

著作権（c）The Internet Society（2004）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.

この文書は、BCP 78およびwww.rfc-editor.orgに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。ISOCドキュメントの権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。