RFC2438 日本語訳
2438 Advancement of MIB specifications on the IETF Standards Track. M.O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: TXT=13633 bytes) (Also BCP0027) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. O'Dell
Request for Comments: 2438 UUNET Technologies
BCP: 27 H. Alvestrand
Category: Best Current Practice Maxware
B. Wijnen
IBM T. J. Watson Research
S. Bradner
Harvard University
October 1998
コメントを求めるワーキンググループM.オデル要求をネットワークでつないでください: 2438UUNET技術BCP: 27時間Alvestrandカテゴリ: 最も良い現在の練習のJ.ワトソン研究S.ブラドナーハーバード大学Maxware B.Wijnen IBM T.1998年10月
Advancement of MIB specifications on the IETF Standards Track
IETF Standards TrackにおけるMIB仕様の進歩
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
2. Abstract
2. 要約
The Internet Standards Process [1] requires that all IETF Standards Track specifications must have "multiple, independent, and interoperable implementations" before they can be advanced beyond Proposed Standard status. This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process.
インターネットStandards Process[1]は、それらをProposed Standard状態を超えたところまで進めることができる前にすべてのIETF Standards Track仕様には「複数の、そして、独立していて、共同利用できる実装」がなければならないのを必要とします。 このドキュメントはIESGがMIB仕様ドキュメントがこれらの必要条件を満たすかどうか決定するのに使用するプロセスを指定します。 また、それはこのプロセスのために原理について議論します。
3. The Nature of the Problem
3. 問題の性格
The Internet Standards Process [1] requires that for an IETF specification to advance beyond the Proposed Standard level, at least two genetically unrelated implementations must be shown to interoperate correctly with all features and options. There are two distinct reasons for this requirement.
インターネットStandards Process[1]は、すべての特徴とオプションで正しく共同利用するためにIETF仕様がProposed Standardレベルを超えたところまで進むために、少なくとも2つの遺伝学的に関係ない実装を示さなければならないのを必要とします。 この要件の2つの異なった理由があります。
The first reason is to verify that the text of the specification is adequately clear and accurate. This is demonstrated by showing that multiple implementation efforts have used the specification to achieved interoperable implementations.
最初の理由は仕様のテキストが適切に明確であって、正確であることを確かめることです。 複数の実装取り組みが達成された共同利用できる実装に仕様を使用したのを示すことによって、これは示されます。
O'Dell, et. al. Best Current Practice [Page 1] RFC 2438 Advancement of MIB specifications October 1998
etオデル、アル。 MIB仕様1998年10月の最も良いCurrent Practice[1ページ]RFC2438Advancement
The second reason is to discourage excessive options and "feature creep". This is accomplished by requiring interoperable implementation of all features, including options. If an option is not included in at least two different interoperable implementations, it is safe to assume that it has not been deemed useful and must be removed before the specification can advance.
2番目の理由は過度のオプションと「特徴いやな奴」をがっかりさせることです。 これは、オプションを含むすべての特徴の共同利用できる実装を必要とすることによって、達成されます。 オプションが少なくとも2つの異なった共同利用できる実装に含まれていないなら、それを役に立つのは考えられていなくて、仕様が進むことができる前に取り除かなければならないと仮定するのは安全です。
In the case of a protocol specification which specifies the "bits on the wire" exchanged by executing state machines, the notion of "interoperability" is reasonably intuitive - the implementations must successfully "talk to each other", exchanging "bits on the wire", while exercising all features and options.
州のマシンを実行することによって交換して、「ワイヤのビット」を指定するプロトコル仕様の場合では、「相互運用性」の概念は合理的に直感的です--実装は首尾よく「互いに話さなければなりません」、「ワイヤのビット」を交換してすべての特徴とオプションを運動させていて。
In the case of an SNMP Management Information Base (MIB) specification, exactly what constitutes "interoperation" is less obvious. This document specifies how the IESG has decided to judge "MIB specification interoperability" in the context of the IETF Standards Process.
SNMP Management Information基地(MIB)の仕様の場合では、まさに"interoperation"を構成することはそれほど明白ではありません。 IESGが、IETF Standards Processの文脈の「MIB仕様相互運用性」を判断するとどう決めたかをこのドキュメントは指定します。
There are a number of plausible interpretations of MIB specification interoperability, many of which have merit but which have very different costs and difficulties in realization.
MIB仕様相互運用性の多くのもっともらしい解釈があります。(それの多くには長所がありますが、解釈は実現における非常に異なったコストと苦労をします)。
The aim is to ensure that the dual goals of specification clarity and feature evaluation have been met using an interpretation of the concept of MIB specification interoperability that strikes a balance between testing complexity and practicality.
目的は仕様明快と特徴評価の二元的な目標が複雑さと実用性をテストするときバランスをとるMIB仕様相互運用性の概念の解釈を使用することで達成されたのを保証することです。
4. On The Nature of MIB specifications
4. MIB仕様のネイチャーに関して
Compared to "state machine" protocols which focus on procedural specifications, a MIB specification is much more data oriented. To over-generalize, in a typical MIB specification the collection of data type and instance specifications outnumbers inter-object procedural or causal semantics by a significant amount.
手続き上の仕様に焦点を合わせる「州のマシン」プロトコルと比べて、MIB仕様は適応するずっと多くのデータです。 典型的なMIB仕様で総合し過ぎるために、かなりの量に従って、データ型とインスタンス仕様の収集は相互オブジェクトの手続き上の、または、原因の意味論に数でまさります。
A central issue is that a MIB specification does not stand alone; it forms the access interface to the instrumentation underneath it. Without the instrumentation, a MIB has form but no values. Coupled with the large number of objects even in a simple MIB specification, a MIB specification tends to have more of the look and feel of an API or a dictionary than a state machine protocol.
主要な問題はMIB仕様が単独で立たないということです。 それはそれの下でアクセスインタフェースを計装に形成します。 計装がなければ、フォームを持っていますが、MIBにはどんな値もありません。 簡単なMIB仕様さえによる多くのオブジェクトと結合されています、MIB仕様は州のマシンプロトコルよりAPIのルック・アンド・フィールか辞書を持っている傾向があります。
It is important to distinguish between assessing the interoperability of applications which may use or interact with MIBs, and the MIBs themselves. It is fairly obvious that "black-box testing" can be
MIBsと使用するか、または対話するかもしれないアプリケーションの相互運用性を評価して、MIBs自身を見分けるのは重要です。 「ブラックボックステスト」がそうであることができることはかなり明白です。
O'Dell, et. al. Best Current Practice [Page 2] RFC 2438 Advancement of MIB specifications October 1998
etオデル、アル。 MIB仕様1998年10月の最も良いCurrent Practice[2ページ]RFC2438Advancement
applied to such applications and that the approach enjoys a certain maturity in the software engineering arts. A MIB specification, on the other hand is not readily amenable to black box test plans.
そのようなアプリケーションとそれに適用されて、アプローチはソフトウェア工学芸術で、ある円熟を楽しみます。 他方では、MIB仕様は容易にブラックボックス試験計画に従順ではありません。
5. Discussion and Recommended Process
5. 議論とお勧めのプロセス
In order to meet their obligations under the IETF Standards Process, the Operations and Management Area Directors and the IESG must be convinced that each MIB specification advanced to Draft Standard or Internet Standard status is clearly written, that there are the required multiple interoperable implementations, and that all options have been implemented. There are multiple ways to achieve this goal. Appendix A lists some testing approaches that could be used when attempting to document multiple implementations.
IETF Standards Processの下で義務を果たすために、それぞれのMIB仕様がDraft Standardに達したか、またはインターネットStandard状態が明確に書かれていて、必要な倍数共同利用できる実装があって、すべてのオプションが実装されたとOperations、Management Areaディレクター、およびIESGを確信しなければなりません。 この目標を達成する複数の方法があります。 付録Aは複数の実装を記録するのを試みるとき使用できたいくつかのテストアプローチを記載します。
The Full Coverage or Stimulus-Response approaches are very through, and would increase confidence that the requirement has been met, if applied. However, experience in real-world software engineering makes it clear that such confidence comes at an extremely high price; even with the most exhaustive testing, it is often not clear what precisely has been demonstrated by such testing. We believe that both of those standards of evidence are materially beyond what can be reasonably accomplished in an operational sense, and achieving the requisite semantic specifications are even more unlikely.
Full CoverageかStimulus-応答アプローチは、非常に突き抜けて、必要条件を満たしてあるという信用を増強するでしょう、適用されるなら。 しかしながら、本当の世界ソフトウェア工学の経験は、そのような信用が非常に高い価格で来ると断言します。 最も徹底的なテストがあっても、何がテストしながらそのようなものによって正確に示されたかは、しばしば明確であるというわけではありません。 私たちは、証拠のそれらの規格の両方が物質的に操作上の意味で合理的に達成できて、必要な意味仕様を達成するのが、ことであるかを超えてありそうもなくさえあると信じています。
Therefore, the Operations and Management Area and the IESG have adopted a more pragmatic approach to determining the suitability of a MIB specification for advancement on the standards track beyond Proposed Standard status. Each MIB specification suggested for advancement must have one or more advocates who can make a convincing argument that the MIB specification meets the multiple implementation and feature support requirements of the IETF Standards Process. The specific way to make the argument is left to the advocate, but will normally include reports that basic object comparison testing has been done.
したがって、Operations、Management Area、およびIESGはProposed Standard状態を超えた標準化過程の上で前進のためのMIB仕様の適合を決定することへの、より実践的なアプローチを取りました。 前進のために示されたそれぞれのMIB仕様には、MIB仕様が複数の実装を満たすという説得力がある主張と特徴サポートをIETF Standards Processの要件にすることができる1人以上の支持者がいなければなりません。 議論をする特定の方法は、支持者に残されますが、通常、基本的なオブジェクト比較テストが完了していたというレポートを含むでしょう。
Thus any recommendation for the advancement of a MIB specification must be accompanied by an implementation report, as is the case with all requests for the advancement of IETF specifications. The implementation report must include the reasons why the IESG should believe that there are multiple implementations of the MIB specification in question and that the all of the MIB objects in the specification to be advanced are supported in more than one implementation. But note that the prime concern of the IESG will be that the underlying reasons for the interoperable implementations are met, i.e., that the text of the specification is clear and unambiguous, and that features of the specification which have not garnered support have been removed.
したがって、実装レポートでMIB仕様の進歩のためのどんな推薦にも伴わなければなりません、IETF仕様の進歩を求めるすべての要求があるケースのように。 実装レポートがIESGが問題のMIB仕様とその複数の実装があると信じているはずである理由を含まなければならない、進められるべき仕様によるMIBオブジェクトのすべてが1つ以上の実装でサポートされます。 しかし、IESGの最大の関心事が共同利用できる実装の基本的な理由が満たされて、すなわち、仕様のテキストが明確であって、明白であり、サポートを集めていない仕様の特徴を取り除いてあるということであることに注意してください。
O'Dell, et. al. Best Current Practice [Page 3] RFC 2438 Advancement of MIB specifications October 1998
etオデル、アル。 MIB仕様1998年10月の最も良いCurrent Practice[3ページ]RFC2438Advancement
The implementation report will be placed on the IETF web page along with the other pre-advancement implementation reports and will be specifically referred to in the IETF Last-Call. As with all such implementation reports, the determination of adequacy is made by the Area Director(s) of the relevant IETF Area. This determination of adequacy can be challenged during the Last-Call period.
実装レポートは、他のプレ前進実装レポートに伴うIETFウェブページに置かれて、IETF Last-呼び出しで明確に呼ばれるでしょう。 そのようなすべての実装レポートのように、妥当性の決断は関連IETF AreaのAreaディレクターによってされます。 Last-呼び出しの期間、妥当性のこの決断に挑戦できます。
6. Security Considerations
6. セキュリティ問題
Some may view this policy as possibly leading to a reduction in the level of confidence people can have in MIB specifications but the O&M Area Directors and the IESG feel that it will adequately ensure a reasonable evaluation of the level of clarity of MIB specifications and to ensure that unused options can be identified and removed before the advancement of a specification.
ことによると信用の人々のレベルの減少に通じるのがMIBに仕様を持つことができますが、O&M AreaのディレクターとIESGが適切にMIB仕様の明快のレベルの合理的な評価を確実にして、仕様の進歩の前にそれを確実にするために、未使用のオプションを特定して、取り除くことができると感じるとき、或るものはこの方針を見るかもしれません。
Good, clearly written MIB specifications can be of great assistance in the management of the Internet and other networks and thus assist in the reduction of some types of security threats.
良くて、明確に書かれたMIB仕様は、インターネットの管理におけるかなりの支援と他のネットワークがあって、その結果、何人かのタイプの軍事的脅威の減少を助けることができます。
8. References
8. 参照
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
O'Dell, et. al. Best Current Practice [Page 4] RFC 2438 Advancement of MIB specifications October 1998
etオデル、アル。 MIB仕様1998年10月の最も良いCurrent Practice[4ページ]RFC2438Advancement
9. Authors' Addresses
9. 作者のアドレス
Michael D. O'Dell UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031
Inc.3060ウィリアムズ・Driveフェアファクス、マイケルD.オデルUUNET Technologiesヴァージニア 22031
Phone: +1-703-206-5890 EMail: mo@uu.net
以下に電話をしてください。 +1-703-206-5890 メールしてください: mo@uu.net
Harald T. Alvestrand Maxware Pirsenteret N-7005 Trondheim, Norway
ハラルド・T.Alvestrand Maxware Pirsenteret N-7005トロンヘイム(ノルウェー)
Phone: +47-73-54-57-94 EMail: Harald.Alvestrand@maxware.no
以下に電話をしてください。 +47-73-54-57-94はメールされます: Harald.Alvestrand@maxware.no
Bert Wijnen IBM T. J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
バートWijnen IBM T.J.ワトソン研究Schagen33 3461GLリンスホーテン・オランダ
Phone: +31-348-432-794 EMail: wijnen@vnet.ibm.com
以下に電話をしてください。 +31-348-432-794 メールしてください: wijnen@vnet.ibm.com
Scott Bradner Harvard University 1350 Mass. Ave. Cambridge MA 02138
スコットブラドナーハーバード大学1350マサチューセッツ州 Ave。 ケンブリッジMA 02138
Phone: +1-617-495-3864 EMail: sob@harvard.edu
以下に電話をしてください。 +1-617-495-3864 メールしてください: sob@harvard.edu
O'Dell, et. al. Best Current Practice [Page 5] RFC 2438 Advancement of MIB specifications October 1998
etオデル、アル。 MIB仕様1998年10月の最も良いCurrent Practice[5ページ]RFC2438Advancement
Appendix A
付録A
A. Some Testing Alternatives
A。 いくつかのテスト選択肢
The IESG debated a number of interoperability and testing models in formulating this specification. The following list is not an exhaustive enumeration of the alternatives, but it does capture the major plausible models which were examined in the course of the discussion.
IESGはこの仕様を定式化する際に多くの相互運用性とテストモデルと討論しました。 以下のリストは代替手段の網羅的列挙ではありませんが、それは議論の間に調べられた一流のもっともらしいモデルをキャプチャします。
A.1 Basic Object Comparison
A.1の基本的なオブジェクト比較
Assume the requisite two genetically unrelated implementations of the MIB in an SNMP agent and an SNMP management station which can do a "MIB Dump" (extract the complete set of MIB object types and values from the agent implementation). Extract a MIB Dump from each implementation and compare the two dumps to verify that both provide the complete set of mandatory and optional objects and that the individual objects are of the correct types.
「MIBダンプ」ができるSNMPエージェントとSNMP管理局でMIBの2つの必要な遺伝学的に関係ない実装を仮定してください(エージェント実装からMIBオブジェクト・タイプと完全な値を抜粋してください)。 各実装からMIB Dumpを抽出してください、そして、2回の憂鬱を比較して、両方が完全なセットの義務的で任意のオブジェクトを提供して、正しいタイプには個々のオブジェクトがあることを確かめてください。
A.2 Stimulus/Response Testing
A.2刺激/応答テスト
Proceed as in A.1, but in addition, comprehensively exercise the two (network) elements containing the agent implementations to verify that all the MIB objects reflect plausible values in operational conditions. An even stricter interpretation would require that the MIB objects in the two network elements track identically given the identical stimulus. While this would test "read-only" or "monitoring" information obtained from the underlying instrumentation, it is important to observe that such instrumentation is actually an *application* which uses the MIB and is not part of the MIB itself.
A.1のように、すべてのMIBオブジェクトがもっともらしい値を稼動状況に反映することを確かめるのにエージェント実装を含む2つの(ネットワーク)要素をさらに、そして、包括的に運動させるのを除いて、続いてください。 さらに厳しい解釈は、同様に同じ刺激を考えて、2つのネットワーク要素のMIBオブジェクトが跡をつけるのを必要とするでしょう。 これは「書き込み禁止」か基本的な計装から得られた「モニターしている」情報をテストするでしょうが、そのような計装が実際にMIBを使用する*アプリケーション*であり、MIB自身の一部でないことを観測するのは重要です。
A.3 Full Coverage Testing
A.3完全適用範囲テスト
This model extends the notion of Stimulus/Response Testing to its logical extreme. The MIB is viewed as an API and the software engineering notion of full coverage testing is applied to a MIB. This involves exercising all paths through the causal semantics and verifying that all objects change state correctly in all cases. Again, note that much more than the MIB definition is being exercised and evaluated.
このモデルはStimulus/応答Testingの概念について論理的な極端に敷衍しています。 APIと完全適用範囲がテストされるというソフトウェア工学概念がMIBに適用されるとき、MIBは見られます。 これは、原因の意味論を通してすべての経路を運動させて、すべてのオブジェクトが正しく状態を変えることを確かめることをすべてのケースに伴います。 もう一度、それにMIB定義が運動させられて、評価されているよりはるかに注意してください。
O'Dell, et. al. Best Current Practice [Page 6] RFC 2438 Advancement of MIB specifications October 1998
etオデル、アル。 MIB仕様1998年10月の最も良いCurrent Practice[6ページ]RFC2438Advancement
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
O'Dell, et. al. Best Current Practice [Page 7]
etオデル、アル。 最も良い現在の習慣[7ページ]
一覧
スポンサーリンク
