RFC1909 日本語訳
1909 An Administrative Infrastructure for SNMPv2. K. McCloghrie, Ed.. February 1996. (Format: TXT=45773 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group K. McCloghrie, Editor Request for Comments: 1909 Cisco Systems, Inc. Category: Experimental February 1996
ワーキンググループK.McCloghrie、コメントを求めるエディタ要求をネットワークでつないでください: 1909年のシスコシステムズInc.カテゴリ: 実験的な1996年2月
An Administrative Infrastructure for SNMPv2
SNMPv2のための管理インフラストラクチャ
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 2 2. Overview .................................................... 2 2.1 Contexts ................................................... 3 2.2 Authorization: Access Rights and MIB Views ................. 3 2.3 Authentication and Privacy ................................. 4 2.4 Access Control ............................................. 5 2.5 Security Models ............................................ 5 2.6 Proxy ...................................................... 5 3. Elements of the Model ....................................... 7 3.1 SNMPv2 Entity .............................................. 7 3.2 SNMPv2 Agent ............................................... 7 3.3 SNMPv2 Manager ............................................. 8 3.4 SNMPv2 Dual-Role Entity .................................... 8 3.5 View Subtree and Families .................................. 9 3.6 MIB View ................................................... 9 3.7 SNMPv2 Context ............................................. 10 3.7.1 Local SNMPv2 Context ..................................... 11 3.7.2 Proxy SNMPv2 Context ..................................... 11 3.8 SNMPv2 PDUs and Operations ................................. 12 3.8.1 The Report-PDU ........................................... 12 3.9 SNMPv2 Access Control Policy ............................... 13 4. Security Considerations ..................................... 13 5. Editor's Address ............................................ 14 6. Acknowledgements ............................................ 14 7. References .................................................. 14 Appendix A Disambiguating the SNMPv2 Protocol Definition ....... 16 Appendix B Who Sends Inform-Requests? ......................... 17 Appendix B.1 Management Philosophy ............................. 17 Appendix B.2 The Danger of Trap Storms ......................... 17 Appendix B.3 Inform-Requests ................................... 18
1. 序論… 2 2. 概要… 2 2.1の文脈… 3 2.2承認: アクセス権とMIB視点… 3 2.3の認証とプライバシー… 4 2.4 コントロールにアクセスしてください… 5 2.5 セキュリティはモデル化されます… 5 2.6プロキシ… 5 3. モデルのElements… 7 3.1SNMPv2実体… 7 3.2SNMPv2エージェント… 7 3.3SNMPv2マネージャ… 8 3.4SNMPv2ニ重の役割実体… 8 3.5 下位木とファミリーを見てください… 9 3.6MIB視点… 9 3.7SNMPv2文脈… 10 3.7 .1のローカルのSNMPv2関係… 11 3.7 .2プロキシSNMPv2文脈… 11 3.8のSNMPv2 PDUsと操作… 12 3.8 .1 PDUを報告します… 12 3.9 SNMPv2はコントロール方針にアクセスします… 13 4. セキュリティ問題… 13 5. エディタのアドレス… 14 6. 承認… 14 7. 参照… SNMPv2のあいまいさを除く14付録Aが定義について議定書の中で述べます… 16 要求を知らせて発信する付録B? ......................... 17 付録B.1経営哲学… 17 罠という付録B.2危険はどなります… 17付録B.3、要求を知らせます… 18
McCloghrie Experimental [Page 1] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[1ページ]RFC1909
1. Introduction
1. 序論
A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies.
マネージメントシステムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証、承認、アクセスコントロール、およびプライバシーに関する方針を定義する管理フレームワークの下で行われます。
Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.
管理局は管理された要素をモニターして、制御する管理アプリケーションを作成します。 管理された要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
It is the purpose of this document, An Administrative Infrastructure for SNMPv2, to define an administrative framework which realizes effective management in a variety of configurations and environments. The SNMPv2 framework is fully described in [1-6]. This framework is derived from the original Internet-standard Network Management Framework (SNMPv1), which consists of these three documents:
それは、さまざまな構成と環境で効果的な管理がわかる管理フレームワークを定義するためにはこのドキュメント、SNMPv2のためのAn Administrative Infrastructureの目的です。 SNMPv2フレームワークは[1-6]で完全に説明されます。 オリジナルのインターネット標準Network Management Framework(SNMPv1)からこのフレームワークを得ます:(Network Management Frameworkはこれらの3通のドキュメントから成ります)。
STD 16, RFC 1155 [7] which defines the Structure of Management
Information (SMI), the mechanisms used for describing and naming
objects for the purpose of management.
STD16、Management情報(SMI)のStructureを定義するRFC1155[7]、メカニズムは説明と命名に管理の目的のためのオブジェクトを使用しました。
STD 16, RFC 1212 [8] which defines a more concise description
mechanism, which is wholly consistent with the SMI.
STD16、完全にSMIと一致したより簡潔な記述メカニズムを定義するRFC1212[8]。
STD 15, RFC 1157 [9] which defines the Simple Network Management
Protocol (SNMP), the protocol used for network access to managed
objects.
STD15、Simple Network Managementプロトコル(SNMP)(管理オブジェクトへのネットワークアクセスに使用されるプロトコル)を定義するRFC1157[9]。
For information on coexistence between SNMPv1 and SNMPv2, consult [10].
SNMPv1とSNMPv2の間の共存の情報に関しては、[10]に相談してください。
2. Overview
2. 概要
A management domain typically contains a large amount of management information. Each individual item of management information is an instance of a managed object type. The definition of a related set of managed object types is contained in a Management Information Base (MIB) module. Many such MIB modules are defined. For each managed object type it describes, a MIB module defines not only the semantics and syntax of that managed object type, but also the method of identifying an individual instance so that multiple instances of the same managed object type can be distinguished.
管理ドメインは多量の経営情報を通常含んでいます。 経営情報の各個別品目は管理オブジェクトタイプのインスタンスです。 関連する管理オブジェクトタイプの定義はManagement Information基地(MIB)のモジュールで含まれています。 そのような多くのMIBモジュールが定義されます。 それが説明するそれぞれの管理オブジェクトタイプのために、MIBモジュールはその管理オブジェクトタイプの意味論と構文だけではなく、同じ管理オブジェクトタイプの複数のインスタンスを区別できるように個々のインスタンスを特定するメソッドも定義します。
McCloghrie Experimental [Page 2] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[2ページ]RFC1909
2.1. Contexts
2.1. 文脈
Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within the management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices. Thus, in order to identify an individual item of management information within the management domain, its context must be identified in addition to its object type and its instance.
管理ドメインの中に通常、それぞれの管理オブジェクトタイプの多くのインスタンスがあります。 簡単さのために、MIBモジュールで指定されたインスタンスを特定するためのメソッドは、各インスタンスが管理ドメインの中のすべてのインスタンスのセットの中で区別されるのを許容しません。 むしろ、それは管理ドメインの中に各いくらかの範囲だけの中で特定されるべきインスタンスかある「文脈」複数のそのようなものに文脈を許容します。 しばしば、文脈は、フィジカル・デバイス、または恐らく論理的なデバイスです、また、文脈が複数のデバイスを取り囲むことができますが、単一のデバイス、同等の部分集合は複数のデバイスの部分集合です。 したがって、管理ドメインの中で経営情報の個別品目を特定するために、オブジェクト・タイプとそのインスタンスに加えて文脈を特定しなければなりません。
For example, the managed object type, ifDescr [11], is defined as the description of a network interface. To identify the description of device-X's first network interface, three pieces of information are needed, e.g., device-X (the context), ifDescr (the managed object type), and "1" (the instance).
例えば、管理オブジェクトタイプ(ifDescr[11])はネットワーク・インターフェースの記述と定義されます。 デバイスXの最初のネットワーク・インターフェースの記述を特定するのに、情報のスリーピースが必要です、例えば、デバイス-X(文脈)、ifDescr(管理オブジェクトタイプ)、そして、「1インチ(インスタンス)。」
Note that each context has (at least) one globally-unique identification within the management domain. Note also that the same item of management information can exist in multiple contexts. So, an item of management information can have multiple globally-unique identifications, either because it exists in multiple contexts, and/or because each such context has multiple globally-unique identifications.
各文脈が管理ドメインの中に(少なくとも)の1つのグローバルにユニークな識別を持っていることに注意してください。 また、経営情報の同じ項目が複数の文脈に存在できることに注意してください。 それで、経営情報の項目は複数のグローバルにユニークな識別を持つことができます、複数の文脈に存在していて、そのような各文脈には複数のグローバルにユニークな識別があるので。
2.2. Authorization: Access Rights and MIB Views
2.2. 承認: アクセス権とMIB視点
For security reasons, it is often valuable to be able to restrict the access rights of some management applications to only a subset of the management information in the management domain. To provide this capability, access to a context is via a "MIB view" which details a specific set of managed object types (and optionally, the specific instances of object types) within that context. For example, for a given context, there will typically always be one MIB view which provides access to all management information in that context, and often there will be other MIB views each of which contains some subset of the information. So, by providing access rights to a management application in terms of the particular (subset) MIB view it can access for that context, then the management application is restricted in the desired manner.
安全保障上の理由で、管理ドメインでいくつかの管理アプリケーションのアクセス権を経営情報の部分集合だけに制限できるのはしばしば貴重です。 この能力を提供するために、その文脈の中に特定の管理オブジェクトタイプ(任意に、オブジェクトの特定のインスタンスはタイプする)について詳述する「MIB視点」を通して文脈へのアクセスはあります。 例えば、与えられた文脈のために、その文脈にはすべての経営情報へのアクセスを提供する1つのMIB視点が通常いつもあるでしょう、そして、それのそれぞれが情報の何らかの部分集合を含む他のMIB視点がしばしばあるでしょう。 それで、そして、それがその文脈のためにアクセスできる特定の(部分集合)MIB視点に関して管理アプリケーションにアクセス権を提供することによって、管理アプリケーションは希望された方法で制限されます。
Since managed object types (and their instances) are identified via the tree-like naming structure of ISO's OBJECT IDENTIFIERs [12, 1],
以来、管理オブジェクトタイプ(そして、彼らのインスタンス)はISOのOBJECT IDENTIFIERs[12、1]の木のような命名構造で特定されます。
McCloghrie Experimental [Page 3] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[3ページ]RFC1909
it is convenient to define a MIB view as the combination of a set of "view subtrees", where each view subtree is a sub-tree within the managed object naming tree. Thus, a simple MIB view (e.g., all managed objects within the Internet Network Management Framework) can be defined as a single view sub-tree, while more complicated MIB views (e.g., all information relevant to a particular network interface) can be represented by the union of multiple view sub- trees.
それぞれの視点下位木が管理オブジェクト命名木の中の下位木である1セットの「視点下位木」の組み合わせとしてのMIB視点を定義するのは便利です。 したがって、簡単なMIB意見(インターネットNetwork Management Frameworkの中の例えばすべての管理オブジェクト)をただ一つの視点下位木と定義できます、複数の視点サブ木の組合は、より複雑なMIB意見(特定のネットワーク・インターフェースに関連している例えばすべての情報)を表すことができますが。
While any set of managed objects can be described by the union of some number of view subtrees, situations can arise that would require a very large number of view subtrees. This could happen, for example, when specifying all columns in one conceptual row of a MIB table because they would appear in separate subtrees, one per column, each with a very similar format. Because the formats are similar, the required set of subtrees can easily be aggregated into one structure. This structure is named a family of view subtrees after the set of subtrees that it conceptually represents. A family of view subtrees can either be included or excluded from a MIB view.
何らかの数の視点下位木の組合がどんなセットの管理オブジェクトについても説明できる間、非常に多くの視点下位木を必要とする状況は起こることができます。 別々の下位木に現れるでしょう、したがって、MIBテーブルの1つの概念的な行のすべてのコラムを指定するとき、例えば、これは起こることができました、1コラムあたり1つ、それぞれ非常に同様の形式で。 形式が同様であるので、容易に必要なセットの下位木を1つの構造に集めることができます。 この構造はそれが概念的に表す下位木のセットにちなんで視点下位木のファミリーと命名されます。 MIB視点から視点下位木のファミリーを含んでいるか、または除くことができます。
In addition to restricting access rights by identifying (sub-)sets of management information, it is also valuable to restrict the requests allowed on the management information within a particular context. For example, one management application might be prohibited from write-access to a particular context, while another might be allowed to perform any type of operation.
特定することによってアクセス権を制限することに加えた(サブ、)、経営情報のセット、また、特定の文脈の中の経営情報で許された要求を制限するのも貴重です。 例えば、1つの管理アプリケーションがアクセスを書くのから特定の文脈まで禁止されるかもしれません、別のものはどんなタイプの操作も実行できるかもしれませんが。
2.3. Authentication and Privacy
2.3. 認証とプライバシー
The enforcement of access rights requires the means not only to identify the entity on whose behalf a request is generated but also to authenticate such identification. Another security capability which is (optionally) provided is the ability to protect the data within an SNMPv2 operation from disclosure (i.e., to encrypt the data). This is particularly useful when sensitive data (e.g., passwords, or security keys) are accessed via SNMPv2 requests.
アクセス権の実施は単に、要求がに代わって発生している実体を特定するのではなく、そのような識別を認証もするために手段を必要とします。 (任意に)提供される別のセキュリティ能力はSNMPv2操作の中に公開(すなわち、データを暗号化する)からデータを保護する能力です。 SNMPv2要求で極秘データ(例えば、パスワード、またはセキュリティキー)がアクセスされるとき、これは特に役に立ちます。
Recommendations for which algorithms are best for authentication and privacy are subject to change. Such changes may occur as and when new research results on the vulnerability of various algorithms are published, and/or with the prevailing status of export control and patent issues. Thus, it is valuable to allow these algorithms to be specified as parameters, so that new algorithms can be accommodated over time. In particular, one type of algorithm which may become useful in the future is the set of algorithms associated with asymmetric (public key) cryptography.
認証とプライバシーに、アルゴリズムが最も良い推薦は変化を被りやすいです。 同じくらいそして、様々なアルゴリズムの脆弱性の新しい研究結果が発行される輸出管理と特許問題の行き渡っている状態と共にあるとき、そのような変化は起こるかもしれません。 したがって、これらのアルゴリズムがパラメタとして指定されるのを許容するのは貴重です、時間がたつにつれて新しいアルゴリズムに対応できるように。 将来役に立つようになるかもしれない1つのタイプのアルゴリズムは特に、非対称の(公開鍵)暗号に関連しているアルゴリズムのセットです。
Note that not all accesses via SNMPv2 requests need to be secure.
SNMPv2要求を通したすべてのアクセスが、安全である必要であるというわけではないことに注意してください。
McCloghrie Experimental [Page 4] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[4ページ]RFC1909
Indeed, there are purposes for which insecure access is required. One example of this is the ability of a management application to learn about devices of which it has no previous knowledge. Another example is to perform any synchronization which the security algorithms need before they can be used to communicate securely. This need for insecure access is accommodated by defining one of the algorithms for authentication as providing no authentication, and similarly, one of the algorithms for privacy as providing no protection against disclosure. (The combination of these two insecure algorithms is sometimes referred to as "noAuth/noPriv".)
本当に、不安定なアクセスが必要である目的があります。 この1つの例が管理アプリケーションがそれが前の知識を全く持っていないデバイスに関して学ぶ能力です。 別の例はそれらを使用できる前にセキュリティアルゴリズムがしっかりと伝える必要があるどんな同期も実行することです。 不安定なアクセスのこの必要性は同様に認証を全く提供しないと認証のためのアルゴリズムの1つを定義することによって、設備されます、公開に対してノー・プロテクションを提供するとしてのプライバシーのためのアルゴリズムの1つ。 (これらの2つの不安定なアルゴリズムの組み合わせは時々"noAuth/noPriv"と呼ばれます。)
2.4. Access Control
2.4. アクセス制御
An access control policy specifies the types of SNMPv2 requests and associated MIB views which are authorized for a particular identity (on whose behalf a request is generated) when using a particular level of security to access a particular context.
アクセス制御方針は特定の文脈にアクセスするのに特定のレベルのセキュリティを使用するとき特定のアイデンティティ(要求はに代わって発生している)のために認可されるSNMPv2要求と関連MIB視点のタイプを指定します。
2.5. Security Models
2.5. 機密保護モデル
A security model defines the mechanisms used to achieve an administratively-defined level of security for protocol interactions:
機密保護モデルはプロトコル相互作用のために行政上定義されたレベルのセキュリティを達成するのに使用されるメカニズムを定義します:
(1) by defining the security parameters associated with a
communication, including the authentication and privacy algorithms
and the security keys (if any) used.
(1) (もしあれば)のキーが使用した認証を含んでいて、パラメタがコミュニケーションに関連づけたセキュリティ、プライバシーアルゴリズム、およびセキュリティを定義することによって。
(2) by defining how entities on whose behalf requests are generated are
identified.
(2) だれの利益要求が発生しているかの実体がどう特定されるかを定義することによって。
(3) by defining how contexts are identified.
(3) 文脈がどう特定されるかを定義することによって。
(4) by defining the mechanisms by which an access control policy is
derived whenever management information is to be accessed.
(4) アクセスされている経営情報がことであるときはいつも、アクセス制御方針が引き出されるメカニズムを定義することによって。
2.6. Proxy
2.6. プロキシ
It is an SNMPv2 agent which responds to requests for access to management information. Each such request is contained within an SNMPv2 message which provides the capability to perform a single operation on a list of items of management information. Rather than having to identify the context as well as the managed object type and instance for each item of management information, each SNMPv2 message is concerned with only a single context. Thus, an SNMPv2 agent must be able to process requests for all items of management information within the one or more contexts it supports.
それはSNMPv2エージェントです(経営情報へのアクセスを求める要求に応じます)。 そのような各要求は経営情報の項目のリストにただ一つの操作を実行する能力を提供するSNMPv2メッセージの中に含まれています。 むしろ、経営情報に関する各個条のためにまた、文脈が管理オブジェクトタイプとインスタンスであると認識しなければならないよりそれぞれのSNMPv2メッセージはただ一つの文脈だけに関係があります。 したがって、SNMPv2エージェントはそれがサポートする1つ以上の文脈の中で経営情報のすべての項目を求める要求を処理できなければなりません。
McCloghrie Experimental [Page 5] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[5ページ]RFC1909
In responding to a request, an SNMPv2 agent might be acting as a proxy for some other agent. The term "proxy" has historically been used very loosely, with multiple different meanings. These different meanings include (among others):
要求に応じる際に、SNMPv2エージェントはある他のエージェントのためのプロキシとして務めているかもしれません。 「プロキシ」という用語は複数の異なった意味と共に歴史的に非常に緩く使用されました。 これらの異なった意味は以下を含んでいます(特に)。
(1) the forwarding of SNMPv2 requests on to other SNMP agents without
regard for what managed object types are being accessed; for
example, in order to forward SNMPv2 request from one transport
domain to another, or to translate SNMPv2 requests into SNMPv1
requests;
(1) SNMPv2の推進はどんな管理オブジェクトタイプがアクセスされているかへの尊敬なしで他のSNMPにエージェントを要求します。 例えば、1つの輸送ドメインから別のドメインまでのSNMPv2要求を転送するか、または翻訳するために、SNMPv2はSNMPv1に要求を要求します。
(2) the translation of SNMPv2 requests into operations of some non-SNMP
management protocol;
(2) SNMPv2に関する翻訳は、管理が議定書を作るよういくらかの非SNMPの操作に要求します。
(3) support for aggregated managed objects where the value of one
managed object instance depends upon the values of multiple other
(remote) items of management information.
(3) 集められた管理オブジェクトのために、1つの管理オブジェクトインスタンスの値が経営情報の他の複数の(リモート)の項目の値によるところでサポートします。
Each of these scenarios can be advantageous; for example, support for aggregation for management information can significantly reduce the bandwidth requirements of large-scale management activities. However, using a single term to cover multiple different scenarios causes confusion.
それぞれのこれらのシナリオは有利である場合があります。 例えば、経営情報のための集合のサポートは大規模な管理活動に関する帯域幅要件をかなり減らすことができます。 しかしながら、複数の異なったシナリオをカバーするのにただ一つの用語を使用すると、混乱は引き起こされます。
To avoid such confusion, this SNMPv2 administrative framework uses the term "proxy" with a much more tightly defined meaning, which covers only the first of those listed above. Specifically, the distinction between a "regular SNMPv2 agent" and a "proxy SNMPv2 agent" is simple:
そのような混乱を避けるのに、このSNMPv2の管理フレームワークはしっかり非常にもう少し定義された意味と共に「プロキシ」という用語を使用します。(それは、上に記載されたものの1番目だけをカバーします)。 明確に、「レギュラーのSNMPv2エージェント」と「プロキシSNMPv2エージェント」の区別は簡単です:
- a proxy SNMPv2 agent is an SNMPv2 agent which forwards requests on
to other agents according to the context, and irrespective of the
specific managed object types being accessed;
- プロキシSNMPv2エージェントはSNMPv2エージェントです(文脈、アクセスされる特定の管理オブジェクトタイプおよびの如何にかかわらず他のエージェントに要求を転送します)。
- in contrast, an SNMPv2 agent which processes SNMPv2 requests
according to the (names of the) individual managed object types and
instances being accessed, is NOT a proxy SNMPv2 agent from the
perspective of this administrative model.
- 対照的に、SNMPv2がそれのプロセスを要求するSNMPv2エージェント、(名前、)、独特の管理オブジェクトタイプとアクセスされたインスタンスはこの管理モデルの見解からのプロキシSNMPv2エージェントではありません。
Thus, when an SNMPv2 agent acts as a proxy SNMPv2 agent for a particular context, although information on how to forward the request is specifically associated with that context, the proxy SNMPv2 agent has no need of a detailed definition of the MIB view (since the proxy SNMPv2 agent forwards the request irrespective of the managed object types).
どう要求を転送するかの情報が明確にその文脈に関連していますが、SNMPv2エージェントが特定の文脈のためのプロキシSNMPv2エージェントとして務めるとき、したがって、プロキシSNMPv2エージェントにはMIB視点の詳細な定義の必要が全くありません(プロキシSNMPv2エージェントが管理オブジェクトタイプの如何にかかわらず要求を転送するので)。
In contrast, a SNMPv2 agent operating without proxy must have the detailed definition of the MIB view, and even if it needs to issue
MIB視点、必要があっても対照的に、プロキシのないa SNMPv2エージェント操作には詳細な定義がなければならない、問題
McCloghrie Experimental [Page 6] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[6ページ]RFC1909
requests to other agents, that need is dependent on the individual managed object instances being accessed (i.e., not only on the context).
他のエージェントへの要求、アクセスされていて(すなわち、文脈だけでないところの)、その必要性は個々の管理オブジェクトインスタンスに依存しています。
3. Elements of the Model
3. モデルのElements
This section provides a more formal description of the model.
このセクションはモデルの、より正式な記述を提供します。
3.1. SNMPv2 Entity
3.1. SNMPv2実体
An SNMPv2 entity is an actual process which performs management operations by generating and/or responding to SNMPv2 protocol messages in the manner specified in [4]. An SNMPv2 entity assumes the identity of a particular administrative entity when processing an SNMPv2 message.
SNMPv2実体は[4]で指定された方法によるSNMPv2プロトコルメッセージに生成する、そして/または、応じることによって管理操作を実行する実際のプロセスです。 SNMPv2メッセージを処理するとき、SNMPv2実体は特定の管理実体のアイデンティティを仮定します。
An SNMPv2 entity is not required to process multiple protocol messages concurrently, regardless of whether such messages require it to assume the identity of the same or different administrative entity. Thus, an implementation of an SNMPv2 entity which supports more than one administrative entity need not be multi-threaded. However, there may be situations where implementors may choose to use multi-threading.
SNMPv2実体は同時に複数のプロトコルメッセージを処理するのに必要ではありません、そのようなメッセージが同じであるか異なった管理実体のアイデンティティを仮定するためにそれを必要とするかどうかにかかわらず。 したがって、1つ以上の管理実体をサポートするSNMPv2実体の実装はマルチスレッド化される必要はありません。 しかしながら、状況が作成者がマルチスレッド化を使用するのを選ぶかもしれないところにあるかもしれません。
An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on each transport service address for which it is configured to do so. It is a local matter whether an SNMPv2 entity also listens for SNMPv2 messages on any other transport service addresses. In the absence of any other information on where to listen, an SNMPv2 entity must listen on the transport service addresses corresponding to the standard transport-layer "ports" [5] on its local network-layer addresses.
SNMPv2実体はそうするのが構成されているそれぞれの輸送サービスアドレスに関する入って来て、求められていないSNMPv2メッセージの聞こうとします。 また、SNMPv2実体が輸送サービスアドレスに関するいかなる他のもSNMPv2メッセージの聞こうとするかどうかが、地域にかかわる事柄です。 どこで聴くかのいかなる他の情報がないとき、SNMPv2実体はローカルのネットワーク層アドレスで標準のトランスポート層「ポート」に対応する輸送サービスアドレスで[5]を聴かなければなりません。
3.2. SNMPv2 Agent
3.2. SNMPv2エージェント
An SNMPv2 agent is the operational role assumed by an SNMPv2 entity when it acts in an agent role. Specifically, an SNMPv2 agent performs SNMPv2 management operations in response to received SNMPv2 protocol messages (except for inform notifications).
SNMPv2エージェントはエージェントの役割で行動するときSNMPv2実体によって引き受けられた操作上の役割です。 明確に、SNMPv2エージェントが受信されたSNMPv2プロトコルメッセージに対応してSNMPv2管理操作を実行する、(案内、通知)
In order to be manageable, all network components need to be instrumented. SNMPv2 access to the instrumented information is via the managed objects supported by an SNMPv2 agent in one or more contexts.
処理しやすくなるように、すべてのネットワーク要素が、器具を取り付けられる必要があります。 器具を取り付けられた情報へのSNMPv2アクセスが1つ以上の文脈でSNMPv2エージェントによってサポートされた管理オブジェクトであります。
McCloghrie Experimental [Page 7] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[7ページ]RFC1909
3.3. SNMPv2 Manager
3.3. SNMPv2マネージャ
An SNMPv2 manager is the operational role assumed by an SNMPv2 entity when it acts in a manager role on behalf of management applications. Specifically, an SNMPv2 manager initiates SNMPv2 management operations by the generation of appropriate SNMPv2 protocol messages, or when it receives and processes trap and inform notifications.
SNMPv2マネージャは管理アプリケーションを代表してマネージャの役割で行動するときSNMPv2実体によって引き受けられた操作上の役割です。 明確に、SNMPv2マネージャが適切なSNMPv2プロトコルメッセージの世代によるSNMPv2管理操作を開始するか、いつ受信するか、そして、プロセスは、捕らえて、通知を知らせます。
It is interesting to consider the case of managing an SNMPv2 manager. It is highly desirable that an SNMPv2 manager, just like any other networking application, be instrumented for the purposes of being managed. Such instrumentation of an SNMPv2 manager (just like for any other networking application) is accessible via the managed objects supported by an SNMPv2 agent. As such, an SNMPv2 manager is no different from any other network application in that it has instrumentation, but does not itself have managed objects.
SNMPv2マネージャを管理するケースを考えるのはおもしろいです。 SNMPv2マネージャが管理される目的のためにまさしくいかなる他のネットワークアプリケーションのようにも器具を取り付けられるのは、非常に望ましいです。 SNMPv2マネージャ(まさしくいかなる他のネットワークアプリケーションなどのようなも)のそのような計装はSNMPv2エージェントによってサポートされた管理オブジェクトでアクセスしやすいです。 そういうものとして、SNMPv2マネージャはいかなる他のネットワーク応用とも計装を持っていますが、それ自体をするというわけではないという点において異なっていません。管理オブジェクトを持ってください。
That is, an SNMPv2 manager does not itself have managed objects. Rather, it is an associated SNMPv2 agent supporting managed objects which provides access to the SNMPv2 manager's instrumentation.
それ自体ではなく、すなわち、マネージャがするSNMPv2が管理オブジェクトを持っています。 むしろ、SNMPv2マネージャの計装へのアクセスを提供するのは、管理オブジェクトをサポートする関連SNMPv2エージェントです。
3.4. SNMPv2 Dual-Role Entity
3.4. SNMPv2ニ重の役割実体
An SNMPv2 entity which sometimes acts in an agent role and sometimes acts in a manager role, is termed an SNMPv2 dual-role entity. An SNMPv2 dual-role entity initiates requests by acting in a manager role, and processes requests regarding management information accessible to it (locally or via proxy) through acting in an agent role. In the case of sending inform notifications, an SNMPv2 dual- role entity acts in a manager role in initiating an inform notification containing management information which is accessible to it when acting in an agent role.
時々行動するSNMPv2実体は、マネージャの役割でエージェントの役割と時々行動して、SNMPv2ニ重の役割実体と呼ばれます。 SNMPv2ニ重の役割実体は、マネージャの役割で行動することによって要求を開始して、エージェントの役割で行動することでそれ(局所的かプロキシを通した)にアクセス可能な経営情報に関する要求を処理します。 発信の場合では、通知を知らせてください、二元的な役割の実体が開始におけるマネージャの役割で機能させるSNMPv2、エージェントの役割で行動するときそれにアクセス可能な経営情報を含む通知を知らせてください。
An SNMPv2 entity which can act only in an SNMPv2 manager role is not SNMP-manageable, since there is no way to access its management instrumentation. In order to be SNMP-manageable, an SNMPv2 entity must be able to act in an SNMPv2 agent role in order to allow its instrumentation to be accessed. Thus, it is highly desirable that all SNMPv2 entities be either SNMPv2 agents or SNMPv2 dual-role entities.
SNMPv2マネージャの役割だけで行動できるSNMPv2実体はSNMP処理しやすくはありません、管理計装にアクセスする方法が全くないので。 SNMP処理しやすくなるように、SNMPv2実体は計装がアクセスされるのを許容するためにSNMPv2エージェントの役割で行動できなければなりません。 したがって、すべてのSNMPv2実体がSNMPv2エージェントかSNMPv2ニ重の役割実体のどちらかであることが非常に望ましいです。
There are two categories of SNMPv2 dual-role entities: proxy SNMPv2 agents and (so-called) mid-level managers. Proxy SNMPv2 agents only forward requests/responses; they do not originate requests. In contrast, mid-level managers often originate requests. (Note that the term proxy SNMPv2 agent does not include an SNMPv2 agent which translates SNMPv2 requests into the requests of some other management protocol; see section 2.6.)
SNMPv2ニ重の役割実体の2つのカテゴリがあります: プロキシSNMPv2エージェントと(いわゆる)の中間レベルのマネージャ。 プロキシSNMPv2エージェントは要求/応答を進めるだけです。 彼らは要求を溯源しません。 対照的に、中間レベルのマネージャはしばしば要求を溯源します。 (用語プロキシSNMPv2エージェントがSNMPv2エージェントを入れないことに注意してください(ある他の管理プロトコルの要求にSNMPv2要求を翻訳します); セクション2.6を見てください。)
McCloghrie Experimental [Page 8] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[8ページ]RFC1909
3.5. View Subtree and Families
3.5. 視点下位木とファミリー
A view subtree is the set of all MIB object instances which have a common ASN.1 OBJECT IDENTIFIER prefix to their names. A view subtree is identified by the OBJECT IDENTIFIER value which is the longest OBJECT IDENTIFIER prefix common to all (potential) MIB object instances in that subtree.
視点下位木は一般的なASN.1OBJECT IDENTIFIER接頭語をそれらの名前に持っているすべてのMIBオブジェクトインスタンスのセットです。 視点下位木はその下位木におけるすべての(潜在的)のMIBオブジェクトインスタンスに共通の最も長いOBJECT IDENTIFIER接頭語であるOBJECT IDENTIFIER値によって特定されます。
A family of view subtrees is a pairing of an OBJECT IDENTIFIER value (called the family name) together with a bitstring value (called the family mask). The family mask indicates which sub-identifiers of the associated family name are significant to the family's definition.
視点下位木のファミリーはbitstring値(ファミリーマスクと呼ばれる)に伴うOBJECT IDENTIFIER価値(姓と呼ばれる)の組み合わせです。 ファミリーマスクは、関連姓のどのサブ識別子がファミリーの定義に重要であるかを示します。
For each possible managed object instance, that instance belongs to a particular view subtree family if both of the following conditions are true:
それぞれの可能な管理オブジェクトインスタンスのために、以下の条件の両方が本当であるなら、そのインスタンスは特定の視点下位木ファミリーのものです:
o the OBJECT IDENTIFIER name of the managed object instance contains
at least as many sub-identifiers as does the family name, and
o そして管理オブジェクトインスタンスのOBJECT IDENTIFIER名が少なくとも姓と同じくらい多くのサブ識別子を含んでいる。
o each sub-identifier in the OBJECT IDENTIFIER name of the managed
object instance matches the corresponding sub-identifier of the
family name whenever the corresponding bit of the associated family
mask is non-zero.
o 管理オブジェクトインスタンスのOBJECT IDENTIFIER名のそれぞれのサブ識別子は関連ファミリーマスクの対応するビットが非ゼロであるときはいつも、姓の対応するサブ識別子に合っています。
When the configured value of the family mask is all ones, the view subtree family is identical to the single view subtree identified by the family name.
ファミリーマスクの構成された値がすべてものであるときに、視点下位木ファミリーは姓によって特定されたただ一つの視点下位木と同じです。
When the configured value of the family mask is shorter than required to perform the above test, its value is implicitly extended with ones. Consequently, a view subtree family having a family mask of zero length always corresponds to a single view subtree.
上のテストを実行するのが必要であるというよりもファミリーマスクの構成された値が短いときに、値はものでそれとなく広げられます。 その結果、ゼロ・レングスのファミリーマスクを持っている視点下位木ファミリーはいつもただ一つの視点下位木に文通します。
3.6. MIB View
3.6. MIB視点
A MIB view is a subset of the set of all instances of all object types defined according to the SMI [1] within an SNMPv2 context, subject to the following constraints:
MIB視点はSNMPv2文脈の中のSMI[1]に従って以下の規制を条件として定義されたすべてのオブジェクト・タイプのすべてのインスタンスのセットの部分集合です:
o It is possible to specify a MIB view which contains the full set of
all object instances within an SNMPv2 context.
o SNMPv2文脈の中にすべてのオブジェクトインスタンスのフルセットを含むMIB視点を指定するのは可能です。
o Each object instance within a MIB view is uniquely named by an
ASN.1 OBJECT IDENTIFIER value.
o MIB視点の中のそれぞれのオブジェクトインスタンスはASN.1OBJECT IDENTIFIER価値によって唯一命名されます。
As such, identically named instances of a particular object type must be contained within different SNMPv2 contexts. That is, a particular
異なったSNMPv2文脈の中に特定のオブジェクト・タイプのそういうものに、同様に命名されたインスタンスを含まなければなりません。 すなわち、事項
McCloghrie Experimental [Page 9] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[9ページ]RFC1909
object instance name resolves within a particular SNMPv2 context to at most one object instance.
高々1つのオブジェクトインスタンスしか特定のSNMPv2文脈の中のオブジェクトインスタンス名前決心。
A MIB view is defined as a collection of view subtree families, where each view subtree family has a type. The type determines whether the view subtree family is included in, or excluded from, the MIB view.
MIB視点は視点下位木ファミリーの収集と定義されます。(それぞれの視点下位木ファミリーには、そこに、タイプがあります)。 タイプが、視点下位木ファミリーが中に含まれているか、または除かれるかを決心している、MIB視点。
A managed object instance is contained/not contained within the MIB view according to the view subtree families to which the instance belongs:
管理オブジェクトインスタンスは含まれて、視点によると、/がMIB視点の中にインスタンスが属する下位木ファミリーを含まなかったということです:
o If a managed object instance belongs to none of the relevant
subtree families, then that instance is not in the MIB view.
o 管理オブジェクトインスタンスが関連下位木ファミリーのだれのものでもないなら、MIB視点にはそのインスタンスがありません。
o If a managed object instance belongs to exactly one of the relevant
subtree families, then that instance is included in, or excluded
from, the relevant MIB view according to the type of that subtree
family.
o 管理オブジェクトインスタンスはちょうど関連下位木ファミリーのひとりに属します、インスタンスが含まれているか、または除かれるその時、その下位木ファミリーのタイプに従った関連MIB視点。
o If a managed object instance belongs to more than one of the
relevant subtree families, then that instance is included in, or
excluded from, the relevant MIB view according to the type of a
particular one of the subtree families to which it belongs. The
particular subtree family is the one for which, first, the
associated family name comprises the greatest number of sub-
identifiers, and, second, the associated family name is
lexicographically greatest.
o 管理オブジェクトインスタンスが関連下位木ファミリーのひとり、インスタンスが中に含まれているか、または除かれるその時より以上に属すなら、事項のタイプに従って、関連MIBはそれが属する下位木ファミリーのひとりを見ます。 特定の下位木ファミリーは最初に関連姓がサブ識別子の最大数を包括するものです、そして、2番目に、関連姓は辞書編集に最大級です。
3.7. SNMPv2 Context
3.7. SNMPv2文脈
An SNMPv2 context is a collection of management information accessible by an SNMPv2 entity. The collection of management information identified by a context is either local or proxy.
SNMPv2文脈はSNMPv2実体によってアクセス可能な経営情報の収集です。 文脈によって特定された経営情報の収集は、ローカルかプロキシのどちらかです。
For a local SNMPv2 context which is realized by an SNMPv2 entity, that SNMPv2 entity uses locally-defined mechanisms to access the management information identified by the SNMPv2 context.
SNMPv2実体によって実現されるローカルのSNMPv2関係に関しては、そのSNMPv2実体は、SNMPv2文脈によって特定された経営情報にアクセスするのに局所的に定義されたメカニズムを使用します。
For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2 agent to access the management information identified by the SNMPv2 context.
プロキシSNMPv2文脈に関しては、SNMPv2実体は、SNMPv2文脈によって特定された経営情報にアクセスするためにプロキシSNMPv2エージェントとして務めます。
The term remote SNMPv2 context is used at an SNMPv2 manager to indicate a SNMPv2 context (either local or proxy) which is not realized by the local SNMPv2 entity (i.e., the local SNMPv2 entity uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2 agent, to access the management information identified by the SNMPv2 context).
用語のリモートSNMPv2文脈は、地方のSNMPv2実体によって実現されないSNMPv2文脈(ローカルかプロキシのどちらか)を示すのにSNMPv2マネージャで使用されます(すなわち、地方のSNMPv2実体はSNMPv2文脈によって特定された経営情報にアクセスするのにプロキシSNMPv2エージェントとして局所的に定義されたメカニズムも行為も使用しません)。
McCloghrie Experimental [Page 10] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[10ページ]RFC1909
3.7.1. Local SNMPv2 Context
3.7.1. ローカルのSNMPv2関係
A local context refers to a collection of MIB objects which (logically) belong to a single entity within a managed device. When an SNMPv2 entity accesses that management information, it does so using locally-defined mechanisms.
ローカルの関係は管理されたデバイスの中に単一体に(論理的に)属すMIBオブジェクトの収集を参照します。 SNMPv2実体がその経営情報にアクセスするとき、それはそう局所的に定義されたメカニズムを使用にします。
Because a device may contain several such local entities, each local context has associated with it a "local entity" name. Further, because management information changes over time, each local context also has associated with it an associated temporal domain, termed its "local time". This allows, for example, one context to refer to the current values of a device's parameters, and a different context to refer to the values that the same parameters for the same device will have after the device's next restart.
デバイスがそのようないくつかのローカル要素を含むかもしれないので、それぞれのローカルの関係は「ローカル要素」名をそれに関連づけました。 時間がたつにつれての変化であり、それぞれのローカルの関係も関連時のドメインをそれに関連づけたという経営情報が「現地時間」を呼んだので、促進します。 これで、例えば、1つの文脈が、同じデバイスのための同じパラメタがデバイスの次の再開の後に持っている値について言及するためにデバイスのパラメタの現行価値、および異なった文脈を示すことができます。
3.7.2. Proxy SNMPv2 Context
3.7.2. プロキシSNMPv2文脈
A proxy relationship exists when a proxy SNMPv2 agent processes a received SNMPv2 message (a request or a response) by forwarding it to another entity, solely according to the SNMPv2 context of the received message. Such a context is called a proxy SNMPv2 context. When an SNMPv2 entity processes management requests/responses for a proxy context, it is operating as a proxy SNMPv2 agent.
プロキシSNMPv2エージェントが別の実体にそれを送ることによって受信されたSNMPv2メッセージ(要求か応答)を処理するとき、プロキシ関係は存在しています、唯一受信されたメッセージのSNMPv2文脈によると。 そのような文脈はプロキシSNMPv2文脈と呼ばれます。 SNMPv2実体がプロキシ文脈のための管理要求/応答を処理するとき、それはプロキシSNMPv2エージェントとして作動しています。
The transparency principle that defines the behavior of an SNMPv2 entity in general, applies in particular to a proxy SNMPv2 context:
一般に、SNMPv2実体の振舞いを定義して、プロキシSNMPv2文脈に特に適用される透明原則:
The manner in which a receiving SNMPv2 entity processes SNMPv2
protocol messages sent by another SNMPv2 entity is entirely
transparent to the sending SNMPv2 entity.
受信SNMPv2実体が別のSNMPv2実体によって送られたSNMPv2プロトコルメッセージを処理する方法は送付SNMPv2実体に完全に見え透いています。
Implicit in the transparency principle is the requirement that the semantics of SNMPv2 management operations are preserved between any two SNMPv2 peers. In particular, the "as if simultaneous" semantics of a
透明原則で暗黙であることは、SNMPv2管理操作の意味論がどんな2人のSNMPv2同輩の間にも保存されるという要件です。 特に「まるで同時であるかのように」aの意味論
Set operation are extremely difficult to guarantee if its scope extends to management information resident at multiple network locations. Note however, that agents which support the forwarding of Set operations concerning information at multiple locations are not considered to be proxy SNMPv2 agents (see section 2.6 above).
範囲が複数のネットワークの位置で経営情報の居住者に達するなら、集合演算は保証するのが非常に難しいです。 しかしながら、複数の所在地で情報に関してSet操作の推進をサポートするそのエージェントがプロキシSNMPv2エージェントであることは考えられないことに(セクション2.6が上であることを見てください)注意してください。
Also implicit in the transparency principle is the requirement that, throughout its interaction with a proxy SNMPv2 agent, an SNMPv2 manager is supplied with no information about the nature or progress of the proxy mechanisms used to perform its requests. That is, it should seem to the SNMPv2 manager (except for any distinction in an
また、透明原則で暗黙であることが、プロキシSNMPv2エージェントとの相互作用の間中自然の情報を全くSNMPv2マネージャに提供しないという要件であるかプロキシメカニズムの進歩は以前はよく要求を実行していました。 SNMPv2マネージャにとって見えるべきである、(中のどんな区別
McCloghrie Experimental [Page 11] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[11ページ]RFC1909
underlying transport address) as if it were interacting via SNMPv2 directly with the proxied device. Thus, a timeout in the communication between a proxy SNMPv2 agent and its proxied device should be represented as a timeout in the communication between the SNMPv2 manager and the proxy SNMPv2 agent. Similarly, an error response from a proxied device should - as much as possible - be represented by the corresponding error response in the interaction between the proxy SNMPv2 agent and SNMPv2 manager.
基本的な輸送アドレス) まるで直接proxiedデバイスがあるSNMPv2を通して相互作用しているかのように。 したがって、プロキシSNMPv2エージェントとそのproxiedデバイスとのコミュニケーションにおけるタイムアウトはSNMPv2マネージャとプロキシSNMPv2エージェントとのコミュニケーションにおけるタイムアウトとして表されるべきです。 同様に、proxiedデバイスからの誤り応答はそうするべきです--できるだけ、プロキシSNMPv2エージェントとSNMPv2マネージャとの相互作用で対応する誤り応答で表されてください。
3.8. SNMPv2 PDUs and Operations
3.8. SNMPv2 PDUsと操作
An SNMPv2 PDU is defined in [4]. Each SNMPv2 PDU specifies a particular operation, one of:
SNMPv2 PDUは[4]で定義されます。 各SNMPv2 PDUは特定の操作、1を指定します:
GetBulkRequest
GetNextRequest
GetRequest
Inform
Report
Response
SNMPv2-Trap
SetRequest
GetBulkRequest GetNextRequest GetRequestはレポート応答SNMPv2-罠SetRequestに知らせます。
3.8.1. The Report-PDU
3.8.1. PDUを報告します。
[4] requires that an administrative framework which makes use of the Report-PDU must define its usage and semantics. With this administrative framework, the Report-PDU differs from the other PDU types described in [4] in that it is not a protocol operation between SNMPv2 managers and agents, but rather is an aspect of error- reporting between SNMPv2 entities. Specifically, it is an interaction between two protocol engines.
[4]は、Report-PDUを利用する管理フレームワークがその用法と意味論を定義しなければならないのを必要とします。 この管理フレームワークで、Report-PDUはそれがSNMPv2マネージャとエージェントの間のプロトコル操作でないという点において[4]で説明された他のPDUタイプと異なっていますが、むしろSNMPv2実体の間で報告する誤りの局面です。 明確に、それは2台のプロトコルエンジンの間の相互作用です。
A communication between SNMPv2 entities is in the form of an SNMPv2 message. Such a message is formatted as a "wrapper" encapsulating a PDU according to the "Elements of Procedure" for the security model used for transmission of the message.
SNMPv2実体のコミュニケーションがSNMPv2メッセージの形にあります。 そのようなメッセージは、「手順のElements」に従ってメッセージの伝達に使用される機密保護モデルのためにPDUをカプセル化しながら、「ラッパー」としてフォーマットされます。
While processing a received communication, an SNMPv2 entity may determine that the received message is unacceptable due to a problem associated with the contents of the message "wrapper". In this case, an appropriate counter is incremented and the received message is discarded without further processing (and without transmission of a Response-PDU).
受信されたコミュニケーションを処理している間、SNMPv2実体は、受信されたメッセージが「ラッパー」というメッセージのコンテンツに関連している問題のために容認できないことを決定するかもしれません。 この場合、適切なカウンタは増加されています、そして、受信されたメッセージはさらなる処理(そしてResponse-PDUのトランスミッションなしで)なしで捨てられます。
However, if an SNMPv2 entity acting in the agent role makes such a determination, then after incrementing the appropriate counter, it may be required to generate a Report-PDU and to send it to the
しかしながら、SNMPv2実体であるなら、エージェントの役割で行動するのはそして、適切なカウンタを増加した後にReport-PDUを生成して、それを送るそれが必要であるかもしれないそのような決断をします。
McCloghrie Experimental [Page 12] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[12ページ]RFC1909
transport address which originated the received message.
受信されたメッセージを溯源したアドレスを輸送してください。
If the agent is able to determine the value of the request-id field of the received PDU [4], then it must use that value for the request-id field of the Report-PDU. Otherwise, the value 2147483647 is used.
エージェントが容認されたPDU[4]の要求イド分野の値を決定できるなら、それはReport-PDUの要求イド分野にその値を使用しなければなりません。 さもなければ、値2147483647は使用されています。
The error-status and error-index fields of the Report-PDU are always set to zero. The variable-bindings field contains a single variable: the identity of the counter which was incremented and its new value.
Report-PDUのエラー状況と誤りインデックス部はいつもゼロに設定されます。 変項束縛分野はただ一つの変数を含んでいます: 増加されたカウンタとその新しい価値のアイデンティティ。
There is at least one case in which a Report-PDU must not be sent by an SNMPv2 entity acting in the agent role: if the received message was tagged as a Report-PDU. Particular security models may identify other such cases.
Report-PDUがエージェントの役割で行動するSNMPv2実体によって送られてはいけない少なくとも1つの場合があります: 受信されたメッセージがReport-PDUとしてタグ付けをされたなら。 特定の機密保護モデルは他のそのような場合を特定するかもしれません。
3.9. SNMPv2 Access Control Policy
3.9. SNMPv2アクセス制御方針
An SNMPv2 access policy specifies the types of SNMPv2 operations authorized for a particular identity using a particular level of security, and if the operation is to be performed on a local SNMPv2 context, two accessible MIB views. The two MIB views are a read-view and a write-view. A read-view is a set of object instances authorized for the identity when reading objects. Reading objects occurs when processing a retrieval (get, get-next, get-bulk) operation and when sending a notification. A write-view is the set of object instances authorized for the identity when writing objects. Writing objects occurs when processing a set operation. An identity's access rights may be different at different agents.
SNMPv2アクセス方針は操作が特定のアイデンティティのために特定のレベルのセキュリティを使用することで認可されて、ローカルのSNMPv2関係(2つのアクセスしやすいMIB視点)に実行されることであるならSNMPv2操作のタイプを指定します。 2つのMIB視点が、読書視点とaです。視点を書きます。 読書視点はオブジェクトを読むときアイデンティティのために認可された1セットのオブジェクトインスタンスです。 通知書を送りながら検索(気付いて、嵩を得るのに得る)操作といつを処理するかとき、オブジェクトを読むのは起こります。 視点を書くのは、オブジェクトを書くときアイデンティティのために認可されたオブジェクトインスタンスのセットです。 集合演算を処理するとき、オブジェクトを書くのは起こります。 アイデンティティのアクセス権は異なったエージェントで異なっているかもしれません。
A security model defines how an SNMPv2 access policy is derived; however, the application of an SNMPv2 access control policy is performed only:
機密保護モデルはSNMPv2アクセス方針がどう引き出されるかを定義します。 しかしながら、SNMPv2アクセス制御方針の適用が実行される、単に:
o on receipt of GetRequest, GetNextRequest, GetBulkRequest, and
SetRequest operations; and
o GetRequest、GetNextRequest、GetBulkRequest、およびSetRequest操作を受け取り次第。 そして
o prior to transmission of SNMPv2-Trap and Inform operations.
o SNMPv2-罠とInform操作の送信の前に。
Note that application of an SNMPv2 access control policy is never performed for Response or Report operations.
SNMPv2アクセス制御方針の適用がResponseかReport操作のために決して実行されないことに注意してください。
4. Security Considerations
4. セキュリティ問題
Security issues are not directly discussed in this memo.
このメモで直接安全保障問題について議論しません。
McCloghrie Experimental [Page 13] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[13ページ]RFC1909
5. Editor's Address
5. エディタのアドレス
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US
西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 526 5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1 5260年の408 526メール: kzm@cisco.com
6. Acknowledgements
6. 承認
This document is the result of significant work by three major contributors:
このドキュメントは3人の一流の貢献者による重要な仕事の結果です:
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Glenn W. Waters (Bell-Northern Research Ltd., gwaters@bnr.ca)
キースMcCloghrie(シスコシステムズ、 kzm@cisco.com )マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング、 mrose@dbc.mtview.ca.us )グレンW.水域(ベル-北研究株式会社、 gwaters@bnr.ca )
The authors wish to acknowledge James M. Galvin of Trusted Information Systems who contributed significantly to earlier work on which this memo is based, and the general contributions of members of the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and Steven L. Waldbusser.
作者はこのメモが基づいている前に働くためにかなり貢献したTrusted情報システムのジェームス・M.ガルビン、および特にSNMPv2作業部会、アレックセイ・Y.ロマーノフ、およびスティーブンL.Waldbusserのメンバーの一般的な貢献を承諾したがっています。
A special thanks is extended for the contributions of:
以下の貢献のために特別な感謝を表します。
Uri Blumenthal (IBM)
Shawn Routhier (Epilogue)
Barry Sheehan (IBM)
Bert Wijnen (IBM)
ユリ・ブルーメンソル(IBM)ショーンRouthier(エピローグ)バリトンサックスシーハン(IBM)バートWijnen(IBM)
7. References
7. 参照
[1] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[1] SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。
[2] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[2] SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[3] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S., Waldbusser, "Conformance Statements for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[3] SNMPv2作業部会とケースとJ.とMcCloghrieとK.とローズ、M.とS.、Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための順応声明」RFC1904(1996年1月)。
McCloghrie Experimental [Page 14] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[14ページ]RFC1909
[4] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[4] SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Waldbusser, S., "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[5] SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびWaldbusser、S.は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
[6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Waldbusser, S., "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1907,
January 1996.
[6] SNMPv2作業部会とケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための管理情報ベース」RFC1907(1996年1月)。
[7] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990.
[7]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)
[8] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[8] ローズ、M.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, MIT Laboratory for Computer
Science, May 1990.
[9] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。
[10] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
Waldbusser, S., "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC 1908, January
1996.
[10] SNMPv2作業部会とケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「インターネット標準ネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存」RFC1908(1996年1月)。
[11] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces
Group of MIB-II", RFC 1573, Cisco Systems, FTP Software, January
1994.
[11]McCloghrie、K.、およびF.Kastenholz、「MIB-IIのインタフェースグループの発展」、RFC1573、シスコシステムズFTPソフトウェア(1994年1月)。
[12] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[12] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
McCloghrie Experimental [Page 15] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[15ページ]RFC1909
APPENDIX A - Disambiguating the SNMPv2 Protocol Definition
付録A--SNMPv2プロトコル定義のあいまいさを除くこと。
The descriptions in [4] of the role in which an SNMPv2 entity acts when sending an Inform-Request PDU are ambiguous. The following updates serve to remove those ambiguities.
Inform-要求PDUを送るときSNMPv2実体が行動する役割の[4]の記述はあいまいです。 以下のアップデートは、それらのあいまいさを取り除くのに役立ちます。
(1) Add the following sentence to section 2.1:
(1) 以下の文をセクション2.1に追加してください:
Further, when an SNMPv2 entity sends an inform notification,
it acts in a manager role in respect to initiating the
operation, but the management information contained in the
inform notification is associated with that entity acting in
an agent role. By convention, the inform is sent from the
same transport address as the associated agent role is
listening on.
SNMPv2実体が発信するとき、促進する、通知を知らせてください、しかし、操作を開始することに関してマネージャの役割、経営情報で中に含まれているのに行動する、その実体がエージェントの役割で行動している状態で、関連づけられた通知を知らせてください。 知らせてください。コンベンションで送る、関連エージェントの役割としてのアドレスが聴く同じ輸送から、送ります。
(2) Modify the last sentence of the second paragraph in section 2.3:
(2) セクション2.3における、第2パラグラフに関する最後の文を変更してください:
This type is used by one SNMPv2 entity, acting in a manager
role, to notify another SNMPv2 entity, also acting in a
manager role, of management information associated with the
sending SNMPv2 entity acting in an agent role.
このタイプは1つのSNMPv2実体によって使用されます、別のSNMPv2実体に通知するためにマネージャの役割で行動して、また、エージェントの役割で行動する送付SNMPv2実体に関連している経営情報のマネージャの役割で行動して。
(3) Modify the second paragraph of section 4.2 (concerning the
generation of Inform-Request PDUs):
(3) セクション4.2(Inform-要求PDUsの世代に関する)の第2パラグラフを変更してください:
It is mandatory that all SNMPv2 entities acting in a manager
role be able to generate the following PDU types: GetRequest-
PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
and Response-PDU; further, all such implementations must be
able to receive the following PDU types: Response-PDU,
SNMPv2-Trap-PDU, InformRequest-PDU. It is mandatory that all
dual-role SNMPv2 entities must be able to generate an Inform-
Request PDU.
マネージャの役割で行動するすべてのSNMPv2実体が以下のPDUタイプを生成することができるのは、義務的です: GetRequest- PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、および応答-PDU。 さらに、そのようなすべての実装が以下のPDUタイプを受けることができなければなりません: 応答-PDU、SNMPv2罠PDU、InformRequest-PDU。 すべてのニ重の役割SNMPv2実体がInform要求PDUを生成することができなければならないのは、義務的です。
(4) Modify the first paragraph of section 4.2.7:
(4) セクション4.2.7の第一節を変更してください:
An InformRequest-PDU is generated and transmitted at the
request of an application in a SNMPv2 entity acting in a
manager role, that wishes to notify another application (via
an SNMPv2 entity also acting in a manager role) of information
in a MIB view which is accessible to the sending SNMPv2 entity
when acting in an agent role.
InformRequest-PDUはマネージャの役割で行動するSNMPv2実体におけるアプリケーションの依頼で生成されて、伝えられて、それはエージェントの役割で行動するとき送付SNMPv2実体にアクセスしやすいMIB視点における、情報の別のアプリケーション(また、マネージャの役割で行動するSNMPv2実体を通した)に通知したがっています。
McCloghrie Experimental [Page 16] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[16ページ]RFC1909
APPENDIX B - Who Sends Inform-Requests?
付録B--だれが要求を知らせて発信しますか?
B.1. Management Philosophy
B.1。 経営哲学
Ever since its beginnings as SGMP, through its definition as SNMPv1, and continuing with the definition of SNMPv2, SNMP has embodied more than just a management protocol and the definitions of MIB objects. Specifically, SNMP has also had a fundamental philosophy of management, consisting of a number of design strategies. These strategies have always included the following:
SGMPとしての始め以来、定義とSNMPv1を、SNMPv2の定義で続くことで、SNMPはまさしく管理プロトコルとMIBオブジェクトの定義以上を具体化しています。 明確に、また、多くのデザイン戦略から成って、SNMPには基本的な経営哲学がありました。 これらの戦略はいつも以下を含んでいました:
(1) The impact of incorporating an SNMP agent into a system should be
minimal, so that both: a) it is feasible to do so even in the
smallest/cheapest of systems, and b) the operational role and
performance of a system is not compromised by the inclusion of an
SNMP agent. This promotes widespread development, which allows
ubiquitous deployment of manageable systems.
(1) SNMPエージェントをシステムに組み入れる影響が最小限であるべきであり、そうがそれである、両方: a) 最も小さいか最も安いシステム、およびb)でさえそう操作上の役割を果たすのが可能であり、SNMPエージェントの包含でシステムの性能は感染されません。 これは広範囲の開発を促進します。(それは、処理しやすいシステムの遍在している展開を許します)。
(2) Every system (potentially) incorporates an SNMP agent. In
contrast, the number of SNMP managers is limited. Thus, there is a
significantly larger number of SNMP agents than SNMP managers.
Therefore, overall system development/complexity/cost is optimized
if the SNMP agent is allowed to be simple and any required
complexity is performed by an SNMP manager.
(2) あらゆるシステムが(潜在的に)SNMPエージェントを取り入れます。 対照的に、SNMPマネージャの数は限られています。 したがって、SNMPマネージャよりかなり多くのSNMPエージェントがいます。 したがって、SNMPエージェントが簡単であることが許容されていて、何か必要な複雑さがSNMPマネージャによって実行されるなら、総合体系開発/複雑さ/費用は最適化されています。
(3) The number of unsolicited messages generated by SNMP agents is
minimized. This enables the amount of network management traffic
to be controlled by the small number of SNMP managers which are
(more) directly controlled by network operators. In fact, this
control is considered of greater importance than any additional
protocol overhead which might be incurred. Monitoring of network
state at any significant level of detail is accomplished primarily
by SNMP managers polling for the appropriate information, with the
use of unsolicited messages confined to those situations where it
is necessary to properly guide an SNMP manager regarding the timing
and focus of its polling. This strategy is sometimes referred to
as "trap-directed polling".
(3) SNMPエージェントによって生成されたお節介なメッセージの数は最小にされます。 これは、ネットワークマネージメントトラフィックの量がネットワーク・オペレータによって直接(さらに)制御されるSNMPマネージャの少ない数によって制御されるのを可能にします。 事実上、このコントロールは被られるどんな追加議定書オーバーヘッドよりもすばらしい重要性について考えられます。 どんな有意水準の詳細におけるネットワーク状態のモニターも主として適切な情報のためのSNMPマネージャ世論調査で達成されます、お節介なメッセージの使用が世論調査のタイミングと焦点に関して適切にSNMPマネージャを誘導するのが必要であるそれらの状況に閉じ込められている状態で。 この戦略は時々「罠で指示された世論調査」と呼ばれます。
B.2. The Danger of Trap Storms
B.2。 罠嵐の危険
The need for such control over the amount of network management traffic is due to the potential that the SNMP manager receiving an unsolicited message does not want, no longer wants, or already knows of the information contained in the message. This potential is significantly reduced by having the majority of messages be specific requests for information by SNMP managers and responses (to those requests) from SNMP agents.
ネットワークマネージメントトラフィックの量のそのようなコントロールの必要性は、可能性へのSNMPマネージャがお節介なメッセージを受け取って、欲しくない支払われるべきもの、もう必需品でない、または既にメッセージに含まれた情報を知ります。 SNMPエージェントからのSNMPマネージャと応答(それらの要求への)でメッセージの大部分が情報に関する特定の要求であることを持っていることによって、この可能性はかなり減少します。
McCloghrie Experimental [Page 17] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[17ページ]RFC1909
The danger of not having the amount of network management be controlled in this manner is the potential for a "storm" of useless traps. As a simple example of "useless", consider that after a building power outage, every device in the network sends a coldStart trap, even though every SNMP manager and every network operator already knows what happened. For a simple example of "storm", consider the result if each transmitted trap caused the sending of another. The greater the number of problems in the state of the network, the greater the risk of such a storm occurring, especially in the unstructured, heterogeneous environment typical of today's internets.
ネットワークマネージメントの量が制御させていないという危険はこの様に役に立たない罠の「嵐」の可能性です。 「役に立ちません」の簡単な例として、ビル電力供給停止の後にネットワークにおけるあらゆるデバイスがcoldStart罠を送ると考えてください、すべてのSNMPマネージャとすべてのネットワーク・オペレータが、何が起こったかを既に知りますが。 「嵐」の簡単な例に関しては、それぞれの伝えられた罠が別のものの発信を引き起こしたなら、結果を考えてください。 ネットワークの事情の問題の数が大きければ大きいほど、特に今日のインターネットの不統一で、異機種混在環境典型的に起こるそのような嵐のリスクは、より高いです。
While SNMP philosophy considers the above to be more important than any lack of reliability in unsolicited messages, some users/developers have been wary of using traps because of the use (typically) of an unreliable transport protocol and because traps are not acknowledged. However, following this logic would imply that having acknowledged-traps would make them reliable; of course, this is false since no amount of re- transmission will succeed if the receiver and/or the connectivity to the receiver is down. A SNMP manager cannot just sit and wait and assume the network is fine just because it is not receiving any unsolicited messages.
SNMP哲学が、上記がお節介なメッセージにおける、信頼性のどんな不足よりも重要であると考える間、何人かのユーザ/開発者が頼り無いトランスポート・プロトコルの使用(通常)のため罠が承認されないので罠を使用するのに用心深いです。 しかしながら、この論理に従うのは、承認された罠を持っているのに信頼できるようになるのを含意するでしょう。 もちろん、受信機への受信機、そして/または、接続性が下がっていると再トランスミッションの量が全く成功しないので、これは誤っています。 SNMPマネージャは、ただ座っていて、待っていて、少しのお節介なメッセージも受け取っているだけではないのでネットワークがすばらしいと仮定できません。
B.3. Inform-Requests
B.3。 要求を知らせます。
One of the new features of SNMPv2 is the Inform-request PDU. The Inform-Request contains management information specified in terms of MIB objects for a context supported by the sender. Since by definition, an SNMPv2 manager does not itself have managed objects (see sections 3.3), the managed objects contained in the Inform- request belong to a context of an SNMPv2 agent, just like the managed objects contained in an SNMPv2-Trap.
SNMPv2に関する新機能の1つはInform-要求PDUです。 Inform-要求はMIBオブジェクトに関して送付者によってサポートされた文脈に指定された経営情報を含んでいます。 定義上SNMPv2マネージャが含んでいるので、それ自体はSNMPv2-罠に管理オブジェクト(セクション3.3を見る)、中に含まれたInformがまさしく管理オブジェクトのようにSNMPv2エージェントの文脈に属すよう要求する管理オブジェクトを含むというわけではありませんでした。
However, it is not the purpose of an Inform-request to change the above described philosophy, i.e., it would be wrong to consider it as an "acknowledged trap". To do so, would make the likelihood and effect of trap storms worse. Recall the building power outage example: with regular traps, the SNMP manager's buffer just overflows when it receives messages faster than it can cope with; in contrast, if every device in the network were to send a coldStart Inform-request, then after a power outage, all will re-transmit their Inform-request several times unless the receiving SNMP managers send responses. In the best case when no messages are lost or re- transmitted, there are twice as many useless messages; in the worst case, the SNMP manager is unable to respond at all and every message is re-transmitted its maximum number of times.
しかしながら、上の説明された哲学を変えるのが、Inform-要求の目的でない、すなわち、それが「承認された罠」であるとみなすのは間違っているでしょう。 そうするために、罠嵐の見込みと効果をより悪くするでしょう。 ビルパワー供給停止の例を思い出してください: 対処できるより速くメッセージを受け取るとき、通常の罠で、SNMPマネージャのバッファはただあふれます。 対照的に、ネットワークにおけるあらゆるデバイスがcoldStart Inform-要求を送るつもりであり、受信SNMPマネージャが応答を送らないと、電力供給停止の後に、すべてが何度か彼らのInform-要求を再送するでしょう。 メッセージが全く失われてもいませんし、再送られもしないときの最も良い場合には、2倍の役に立たないメッセージがあります。 最悪の場合には、SNMPマネージャは全く応じることができません、そして、あらゆるメッセージが再送されます。最大数の倍。
McCloghrie Experimental [Page 18] RFC 1909 An SNMPv2 Administrative Infrastructure February 1996
インフラストラクチャ1996年2月の管理のSNMPv2あたりMcCloghrieの実験的な[18ページ]RFC1909
The above serves to explain the rationale behind the definition (see Appendix A's update to section 4.2.7 of [4]) that:
上記は、定義の後ろで原理について説明するのに役立ちます。(Appendix Aのアップデートを[4])そのセクション4.2.7まで見てください:
An InformRequest-PDU is generated and transmitted at the request of
an application in a SNMPv2 entity acting in a manager role, that
wishes to notify another application (via an SNMPv2 entity also
acting in a manager role) of information in a MIB view which is
accessible to the sending SNMPv2 entity when acting in an agent
role.
InformRequest-PDUはマネージャの役割で行動するSNMPv2実体におけるアプリケーションの依頼で生成されて、伝えられて、それはエージェントの役割で行動するとき送付SNMPv2実体にアクセスしやすいMIB視点における、情報の別のアプリケーション(また、マネージャの役割で行動するSNMPv2実体を通した)に通知したがっています。
This definition says that SNMPv2 agents do not send Inform-Requests, which has three implications (ordered in terms of importance):
この定義は、SNMPv2エージェントがInform-要求を送らないと言います(3つの意味(重要性に関して、注文する)があります):
(1) the number of devices which send Inform-requests is required to be
a small subset of all devices in the network;
(1) Inform-要求を送るデバイスの数がネットワークにおけるすべてのデバイスの小さい部分集合になるのに必要です。
(2) while some devices traditionally considered to be SNMP agents are
perfectly capable of sending Inform-requests, the overall system
development/complexity/cost is not increased as it would be by
having to configure/re-configure every SNMPv2 agent as to which
Inform-requests to send where and how often; and
(2) いくつかのデバイスが、エージェントがSNMPに、なるようにInform-要求を完全に送ることができると伝統的に考えましたが、それがどれくらいの頻度でどこを送るかというどのInform-要求に関してすべてのSNMPv2エージェントを構成しなければならないか、または再構成しなければならないかによってあるだろうというのに従って、総合体系開発/複雑さ/費用は増強されません。 そして
(3) the cost of implementing an SNMPv2 agent in the smallest/cheapest
system is not increased.
(3) 最も小さいか最も安いシステムでSNMPv2エージェントを実装する費用は増強されません。
McCloghrie Experimental [Page 19]
McCloghrie実験的です。[19ページ]
一覧
スポンサーリンク
