RFC3933 日本語訳
3933 A Model for IETF Process Experiments. J. Klensin, S. Dawkins. November 2004. (Format: TXT=14409 bytes) (Also BCP0093) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Klensin Request for Comments: 3933 S. Dawkins BCP: 93 November 2004 Category: Best Current Practice
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 3933秒間ダウキンズBCP: 11月93日の2004カテゴリ: 最も良い現在の習慣
A Model for IETF Process Experiments
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 (2004).
Copyright(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.
IETFはここ10年間2つの方法の1つで過程変化を設計しています: IESGと、時々限られた地域社会参加と認識との非公式協定、およびプロトコル仕様に使用される同じメカニズムの正式な使用に基づいた発表。 最初のメカニズムは軽量過ぎるとしばしば判明して、秒も大物です。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンドと仕様. . . . . . . . . . . . . . . . . 2 3。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 5 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 5 5。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1。 引用規格。 . . . . . . . . . . . . . . . . . . 5 5.2. 有益な参照. . . . . . . . . . . . . . . . . 5 6。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 6の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 7
Klensin & Dawkins Best Current Practice [Page 1] RFC 3933 A Model for IETF Process Experiments November 2004
IETFの過程のためのモデルが2004年11月に実験するKlensinとダウキンズ最も良い現在の習慣[1ページ]RFC3933
1. Introduction
1. 序論
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の過程(大いに以前に試みられたものよりむしろ「実験を提案して、行ってください、そして、実験を評価してください、そして、次に、運用経験に基づく永久的な手順を確立してください」というモデルを当てにするもの)への変更を行うシステムへの妥協点アプローチを指定します。
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は、利益共同体を特定して、1BoFsを持って、ワーキンググループをチャーターして、共同体の中で変更案について議論して、変化の上でIETF全体のコンセンサスを育んで、(通常)最も良いCurrent Practice仕様を発表するのに[RFC2026]プロトコル標準開発過程を使用しました。 これは、完全な地域社会参加を提供しましたが、柔軟性における費用と共にまた来ました。 IETFがしばしば正式な過程を変えるというわけではなくて(中のIPR明確化[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が賢明にこの思慮深さを運動させないなら、このドキュメントはどんな追加療法も提供しません。
Klensin & Dawkins Best Current Practice [Page 2] RFC 3933 A Model for IETF Process Experiments November 2004
IETFの過程のためのモデルが2004年11月に実験するKlensinとダウキンズ最も良い現在の習慣[2ページ]RFC3933
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 Last Callは開始されます。 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. Last Callの結論のときに、IESGは提案のもっともらしさと適切さを再評価します。 彼らが、提案された実験が適切であると結論を下すなら、明らかにLast Callの間に提起された問題にLast Callで露出されたどんなdefinitional問題もきれいにして、特定して、応じる第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. 次に、ドキュメントと実験を発表します、そして、実験を始めます、そして、公表のためにExperimental RFCとしてドキュメントを転送します。
Klensin & Dawkins Best Current Practice [Page 3] RFC 3933 A Model for IETF Process Experiments November 2004
IETFの過程のためのモデルが2004年11月に実験するKlensinとダウキンズ最も良い現在の習慣[3ページ]RFC3933
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仕様への変更案と共に経験を積むのに、このメカニズム(Experimental RFCsに基づいている)を使用するのが明らかに認可されます。 実験が値を持っているのがわかるまで実験のための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が来るところに関してあいまいです: 1番目でWG、デザインチーム、個人拠出、編集グループ、または他のメカニズムを使用できました、そして、第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.
その都度、手続き上の実験と共に(or not)を進めに行くという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.
私たちは、次に、IESGが最後の10年間取り入れている(そして、それが作った手続き上の例外)手順が正統であるならIESGにはここでこの過程を独力で進むことによって指定された変化を設ける権威があることに注意します。
Klensin & Dawkins Best Current Practice [Page 4] RFC 3933 A Model for IETF Process Experiments November 2004
IETFの過程のためのモデルが2004年11月に実験するKlensinとダウキンズ最も良い現在の習慣[4ページ]RFC3933
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.
このドキュメントの最初の改正はIETF59の間、かなり司令官のArea Directorateとその公開の会議でAvriドーリアと、マーガレット・ワッサーマンと、ハラルドAlvestrandと、議論からの提案とコメントの利益を得ました。 メーリングリスト議論の後に、多量の説明資料は最新版のための別々のドキュメントに移されました。
The first version of this document was posted as an Internet Draft on February 7, 2004.
このドキュメントの最初のバージョンは2004年2月7日にインターネットDraftとして掲示されました。
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] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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]クロッカー、S.、「インターネット規格作業部会(バランスをとっている)組織のための過程」、RFC1396、1993年1月。
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3667] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3667、2004年2月。
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[RFC3668] ブラドナー、S.、「IETF技術による知的所有権」、BCP79、RFC3668、2004年2月。
Klensin & Dawkins Best Current Practice [Page 5] RFC 3933 A Model for IETF Process Experiments November 2004
IETFの過程のためのモデルが2004年11月に実験するKlensinとダウキンズ最も良い現在の習慣[5ページ]RFC3933
6. Authors' Addresses
6. 作者のアドレス
John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
Phone: +1 617 491 5735 EMail: john-ietf@jck.com
以下に電話をしてください。 +1 5735年の617 491メール: john-ietf@jck.com
Spencer Dawkins 1547 Rivercrest Blvd. Allen, TX 75002 USA
スペンサー・ダウキンズ1547Rivercrest Blvd. テキサス75002アレン(米国)
Phone: +1 469 330 3616 EMail: spencer@mcsr-labs.org
以下に電話をしてください。 +1 3616年の469 330メール: spencer@mcsr-labs.org
Klensin & Dawkins Best Current Practice [Page 6] RFC 3933 A Model for IETF Process Experiments November 2004
IETFの過程のためのモデルが2004年11月に実験するKlensinとダウキンズ最も良い現在の習慣[6ページ]RFC3933
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78と、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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Klensin & Dawkins Best Current Practice [Page 7]
KlensinとダウキンズBest現在の習慣[7ページ]
一覧
スポンサーリンク
