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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
時々限られたコミュニティの関与や意識、およびプロトコル仕様のために使用したのと同じメカニズムの正式な使用との非公式の合意に基づき、IESGの発表、：IETFは、プロセスの2つの方法のいずれかで最後の10年間の変化を設計しました。最初のメカニズムは、多くの場合、二あまりにもヘビー級、あまりにも軽量であることが証明されています。
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
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プロセスに変更を加えるのシステム、それらよりもむしろ「提案し、実験を行って、実験を評価して、運用経験に基づく恒久的な手順を確立」モデルに大きく依存しているものにミドルアースアプローチを指定します以前に試みました。
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はまた、興味のあるコミュニティを識別する1つ以上のBoFs、チャーターワーキンググループを開催、コミュニティ内の変更案を議論するために、[RFC2026]プロトコル標準に開発プロセスを使用した、変更に関するIETF全体のコンセンサスを開発し、 （通常は）最も良い現在の練習の仕様を公開します。これは、完全なコミュニティの関与を提供するだけでなく、柔軟でコストで来ました。 IETFは、多くの場合、その正式なプロセスを変更しない（で知的財産権の明確化[RFC3667、RFC3668] 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のIDが生成されます（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は、明示的にBCPの仕様への変更案の経験を積むために（実験のRFCに基づいて）このメカニズムを使用することが許可されています。実験は値を有することが見出されるまで、実験のための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及び/又は第三の工程で使用することができるが、具体的なメカニズムが必要とされない、および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.
それぞれのケースで、手続き実験、または1つに至るまでの段階で、前方（またはしない）に行くためにIESGの決定は、コミュニティのラフコンセンサスの存在の彼らの判断を反映することが期待されます。その判断は、通常の手順を使用して上訴することができるが、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は、このプロセスをブートストラップにより、ここで指定した変更を制定する権限を持っている、ということに注意してください。
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は、当然のことながら、運動による注意がこのような変更は、プロセスの実験の提案がすべき品質劣化の早期検出と訂正メカニズムが含まれていることを、少なくとも、プロトコルのためのセキュリティレビューの品質と配慮を減らすか、ならないこと発生する。
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ドリア、マーガレットワッサーマン、およびハラルドAlvestrandからの提案やコメントから、と一般エリア総局との議論からとメーリングリストの議論の後IETF 59の間にそのオープン会議で大幅に恩恵を受け、かなりの説明資料を除去しました現在のバージョンのための別のドキュメントへ。
The first version of this document was posted as an Internet Draft on February 7, 2004.
このドキュメントの最初のバージョンは2004年2月7日にインターネットドラフトとして掲載されました。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC1396] Crocker, S., "The Process for Organization of Internet Standards Working Group (POISED)", RFC 1396, January 1993.
[RFC1396]クロッカー、S.、RFC 1396、1993年1月 "インターネット標準ワーキンググループ（構え）の組織化のためのプロセス"。
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004.
[RFC3667]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3667、2004年2月。
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004.
[RFC3668]ブラドナーの、S.、 "IETF技術の知的財産権"、BCP 79、RFC 3668、2004年2月。
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
ジョン・C Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140 USA
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
電話：+1 617 491 5735 Eメール：john-ietf@jck.com
Spencer Dawkins 1547 Rivercrest Blvd. Allen, TX 75002 USA
スペンサー・ドーキンス1547 Rivercrestブルバードアレン、TX 75002 USA
Phone: +1 469 330 3616 EMail: spencer@mcsr-labs.org
電話：+1 469 330 3616 Eメール：spencer@mcsr-labs.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。