[要約] RFC 2438は、IETF Standards Track上のMIB仕様の進展に関する要約です。その目的は、MIB仕様の進展を促進し、ネットワーク管理の標準化を支援することです。
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
Advancement of MIB specifications on the IETF Standards Track
IETF標準トラックのMIB仕様の進歩
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.
このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
Internet Standards Process [1]では、すべてのIETF Standards Track仕様が「複数の、独立した、相互運用可能な実装」を備えていないと、Proposed Standardステータスを超えることができません。このドキュメントは、MISG仕様ドキュメントがこれらの要件を満たしているかどうかを判断するためにIESGが使用するプロセスを指定します。また、このプロセスの根拠についても説明します。
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.
Internet 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.
最初の理由は、仕様のテキストが十分に明確で正確であることを確認することです。これは、複数の実装作業が仕様を使用して相互運用可能な実装を達成したことを示すことによって示されます。
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管理情報ベース（MIB）仕様の場合、「相互運用」を構成するものはそれほど明確ではありません。このドキュメントでは、IESGがIETF標準プロセスのコンテキストで「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仕様の相互運用性の概念の解釈を使用して、仕様の明確さと機能評価の二重の目標が確実に満たされるようにすることを目的としています。
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 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を使用または相互作用する可能性のあるアプリケーションの相互運用性の評価と、MIB自体を区別することが重要です。 「ブラックボックステスト」がこのようなアプリケーションに適用できること、およびこのアプローチがソフトウェアエンジニアリングの分野で一定の成熟度を享受していることはかなり明白です。一方、MIB仕様は、ブラックボックステスト計画に容易に対応できません。
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標準プロセスの下での義務を果たすために、運用管理エリアディレクターとIESGは、ドラフト標準またはインターネット標準ステータスに進んだ各MIB仕様が明確に記述されていること、必要な複数の相互運用可能な実装があること、およびすべてのオプションが実装されていること。この目標を達成する方法はいくつかあります。付録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.
完全カバレッジまたは刺激応答アプローチは非常に完全であり、適用された場合、要件が満たされているという確信が高まります。ただし、実際のソフトウェアエンジニアリングの経験から、このような信頼は非常に高くつくことが明らかになっています。最も徹底的なテストを行ったとしても、そのようなテストによって何が正確に実証されたのかはしばしば明確ではありません。これらの証拠基準はどちらも、運用上の意味で合理的に達成できるものを大幅に超えており、必要なセマンティック仕様を達成する可能性はさらに低いと考えています。
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.
したがって、運用管理領域とIESGは、提案された標準ステータスを超えた標準トラックの進歩に対するMIB仕様の適合性を決定するために、より実用的なアプローチを採用しています。改善が提案されている各MIB仕様には、MIB仕様がIETF標準プロセスの複数の実装および機能サポート要件を満たしていることを説得できる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.
したがって、IETF仕様の拡張を求めるすべての要求と同様に、MIB仕様の拡張に関する推奨事項には、実装レポートを添付する必要があります。実装レポートには、問題のMIB仕様の実装が複数あること、および拡張する仕様のすべてのMIBオブジェクトが複数の実装でサポートされていることをIESGが信じるべき理由を含める必要があります。ただし、IESGの主な関心事は、相互運用可能な実装の根本的な理由が満たされていること、つまり仕様のテキストが明確で明確であること、およびサポートを獲得していない仕様の機能が削除されたことです。
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 Webページに配置され、IETF Last-Callで具体的に参照されます。そのようなすべての実装レポートと同様に、妥当性の判断は、関連するIETFエリアのエリアディレクターによって行われます。この妥当性の判断は、ラストコール期間中に挑戦することができます。
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エリアディレクターと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仕様は、インターネットやその他のネットワークの管理に非常に役立ち、ある種のセキュリティ脅威の軽減に役立ちます。
[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月。
Michael D. O'Dell UUNET Technologies, Inc. 3060 Williams Drive Fairfax, VA 22031
Michael D. O'Dell UUNET Technologies、Inc. 3060 Williams Drive Fairfax、VA 22031
Phone: +1-703-206-5890
EMail: mo@uu.net
Harald T. Alvestrand Maxware Pirsenteret N-7005 Trondheim, Norway
Harald T. Alvestrand Maxware Pier Center N-7005 Trondheim、ノルウェー
Phone: +47-73-54-57-94
EMail: Harald.Alvestrand@maxware.no
Bert Wijnen IBM T. J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
Bert Wijnen IBM T. J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
Phone: +31-348-432-794
EMail: wijnen@vnet.ibm.com
Scott Bradner Harvard University 1350 Mass. Ave. Cambridge MA 02138
スコットブラッドナーハーバード大学1350 Mass。Ave. Cambridge MA 02138
Phone: +1-617-495-3864
EMail: sob@harvard.edu
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は、この仕様を策定するにあたり、多くの相互運用性とテストモデルについて議論しました。次のリストは代替案の完全な列挙ではありませんが、議論の過程で検討された主要なもっともらしいモデルを捉えています。
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ダンプを抽出し、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と同様に実行しますが、さらに、エージェントの実装を含む2つの（ネットワーク）要素を包括的に実行して、すべてのMIBオブジェクトが操作条件の妥当な値を反映していることを確認します。さらに厳密な解釈では、同じ刺激が与えられた場合、2つのネットワーク要素のMIBオブジェクトが同じように追跡する必要があります。これは、基礎となるインストルメンテーションから取得した「読み取り専用」または「モニタリング」情報をテストしますが、そのようなインストゥルメンテーションは実際にはMIBを使用する*アプリケーション*であり、MIB自体の一部ではないことに注意することが重要です。
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.
このモデルは、刺激/応答テストの概念をその論理的な極限まで拡張します。 MIBはAPIと見なされ、フルカバレッジテストのソフトウェアエンジニアリングの概念がMIBに適用されます。これには、因果的なセマンティクスを介してすべてのパスを実行し、すべてのオブジェクトがすべてのケースで正しく状態を変更することを確認することが含まれます。繰り返しますが、MIB定義よりもはるかに多くのものが実行および評価されていることに注意してください。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。